Security Vulnerabilities On HTC Android Devices

revjtanton writes "In recent updates to some of its devices, HTC introduced a suite of logging tools that collected information. Lots of information. LOTS. Whatever the reason was, whether for better understanding problems on users' devices, easier remote analysis, or corporate evilness — it doesn't matter." That's because "any app on affected devices that requests a single android.permission.INTERNET (which is normal for any app that connects to the web or shows ads)" on one of these phones can now grab all sorts of interesting bits from the logged data.

Comments

Fix

[Adam Zweimiller]

If you are rooted, you can use Titanium Backup to uninstall HTC Loggers or you can manually delete HTCLoggers.apk from /system/app/.

Re:Fix

[Rich0]

There is no problem with "the permissions."

There is an app that runs as root (which means it effectively has all permissions), and it publishes all kinds of data on a TCP port. Anything that can connect to it can just ask for whatever data it wants.

The fix it to get rid of that app, or at least make it not expose that data on that port (which requires editing the app source, and which seems pointless since the only purpose of the app seems to be to bypass the normal permissions model).

Apps that run as root can do whatever they want to - don't like it, don't run the app. That's why generally speaking you shouldn't run random apps as root.

Re:Fix

[stephanruby]

One silver lining at least is that

HTC is one of the very few hardware manufacturers that does provide official instructions for rooting your own device.

Re:Fix

[fuzzyfuzzyfungus]

Arguably there is a problem with "the permissions"; but not in a narrowly technical sense(well, strictly speaking, it might be nice if Android broke network permissions down a little further, so that you could allow an application to access internet resources; but forbid it from connecting to anything on localhost, or allow something to connect to one or more ports on localhost; but not the outside...)

A major vendor is shipping a 'diagnostic' application so fucked that it might as well be a rootkit on a large-but-not-precisely-known number of devices expected to be connected to the internet and in possession of relatively juicy information for most of their operational lives, and nobody in the chain decided that this was maybe a bad idea until 3rd parties discovered it and wrote it up...

This suggests that HTC's "Sense" team might not have any.

Cyanogen Mod

[Anonymous Coward]

Even more reason to root and flash with CyanogenMod or other custom firmware of your choice.

Re:Cyanogen Mod

[izomiac]

Amusingly enough, the core CyanogenMod developers have made it abundantly clear that they vastly prioritize the ability of vendors to spy on users over the user's right to control who has access to personally identifiable data.

(Sorry for using biased language, but I think that denying a user control over hardware they own, especially by an open source project, is just asinine.)

Re:Cyanogen Mod

[Miamicanes]

You don't lose SenseUI from *rooting*, you lose SenseUI from replacing its stock ROM with most community Android builds. The main complaint today about most factory ROMs is that there's no graceful way to pick and choose what you want to keep. To a very, very large extent, you can either poke around and rearrange the furniture a bit (leaving most of the original stuff in place), or you can blow it all away and end up with something that often isn't quite as polished or pretty as what you had before.

The main problem is that the Android team largely left it up to manufacturers to implement core stuff like the Dialer app, and never formally defined how a "Dialer" should interact with a "Phonebook" or "Calendar". So what happens is that someone makes a custom ROM, tries tweaking the Dialer, discovers he can't, blows it away and replaces it, then discovers that it can't seamlessly integrate with anything else on the phone because it doesn't know how to interact with the phonebook or calendar. SO... he reverse engineers the phonebook and calendar on HIS phone, gets it to work with his Dialer of choice, then others try to use it and it blows up on their phones because the phonebook and calendar on THEIR phones communicates in a different way than the phonebook and calendar on HIS phone.

THIS is what people really mean when they talk about Android's "fragmented" frameworks -- there's no official standard for how a modular and extensible dialer app should work or interact with the rest of the system, so every new Dialer ends up being specific to a very small specific group of phones, and version upgrades that upgrade the Dialer app end up breaking everything that was based on the old version's reverse-engineered behavior. SenseUI does things one way, Touchwiz does things another, Motoblur does them a third, and AOSP is off in its own world with several other ways for different families of Dialers+phonebooks to interact with each other and the rest of the world.

I believe one of Google's goals for ICS has been to formally define aspects of the "phonebook/contacts/schedule" system and standardize the intents, so that at least going forward manufacturers who properly implement them will have phones that can be incrementally tweaked without having to blow everything away and throw the baby out with the bathwater the way you (mostly) do now.

YES it is an OS issue

[SuperKendall]

Every time you install an app, a list of permissions to be granted is present to the user for their permission. Now, it may be the case that most users just blindly hit "accept," but that's not an OS issue.

Yes it is. By having a security model that makes it more likely users will accept, that OS has introduced a security flaw.

A better approach is to grant permission at first time of access to a resource, so that you can make a judgement in context of what the app is asking for. Possibly some permissions should be asked for up front anyway, but not all... And by breaking them apart users would think more about granting them.