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.

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 [htcdev.com] your own device.

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.