Slashdot Mirror


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.

15 of 97 comments (clear)

  1. Fix by Adam+Zweimiller · · Score: 4, Interesting

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

    --
    mmm...muffins
    1. Re:Fix by Rich0 · · Score: 3, Informative

      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.

    2. Re:Fix by stephanruby · · Score: 4, Informative

      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.

    3. Re:Fix by fuzzyfuzzyfungus · · Score: 3, Interesting

      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.

    4. Re:Fix by ScrewMaster · · Score: 2

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

      If you are rooted you can just install Cyanogenmod and forget about it.

      --
      The higher the technology, the sharper that two-edged sword.
  2. Cyanogen Mod by Anonymous Coward · · Score: 4, Interesting

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

    1. Re:Cyanogen Mod by izomiac · · Score: 4, Interesting

      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.)

    2. Re:Cyanogen Mod by Miamicanes · · Score: 3, Informative

      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.

    3. Re:Cyanogen Mod by Rich0 · · Score: 2

      I suspect that "their" motive is to keep their options open, and they're not going to get job offers from phone vendors by making it harder to monetize the platform. Steve is now employed by a phone vendor so I doubt he'll ever shake things up that much.

      There are now 3rd-party apps that will block these APIs, which makes me less annoyed with Android.

      Android is FOSS, so you could always make a "PrivacyMod" distro that just tracks CyanogenMod but adds a few patches like these sorts of things. That would be relatively low-maintenance, and if it ever took off it would put considerable pressure on CM to adopt a more user-centric policy.

      I really could care less what is good for app vendors/etc - the phone is mine, and if they can make money off MY phone that is nice, but it isn't at all important to me. I don't hold to the "just don't install the app" model - there is no technical reason why I can't have my cake, eat it too, and send a message to app vendors that they need to restrain themselves or they'll be cut off.

    4. Re:Cyanogen Mod by ScrewMaster · · Score: 2

      Is there at least a grid or DB somewhere of phones vs firmwares that indicates which OEM features are covered, and perhaps by which optional replacement? I thought phone fans were obsessive about collecting those kinds of details about the objects of their fetish.

      This may be helpful to you.

      --
      The higher the technology, the sharper that two-edged sword.
    5. Re:Cyanogen Mod by Miamicanes · · Score: 2

      > Now you understand why Samsung just hired Steve Kondik, founder of the Cyanogenmod project.
      > They need someone like him very badly.

      You're absolutely right. Actually, Steve will help Samsung a lot, because for basically the cost of one happy full-time employee, they've effectively outsourced the long-term maintenance of their phones' firmware to dozens to hundreds of enthusiastic, highly-skilled unpaid volunteers (many of whom would be VERY expensive to hire for real as full-time employees). Samsung has NEVER been good about supporting phones with updates after they've shipped. Cyanogen went a long way towards fixing that, but had a problem -- there were hardware issues that just couldn't be easily solved without access to the proprietary bits of source that Samsung couldn't hand out to members of the public. Now that Steve's an employee under NDA, they can give him the keys to the castle and let him freely build flawless Cyanogen-optimized kernels for Samsung's phones, and leave everything else up to the community.

  3. Re:Why even bother specifying INTERNET perms? by robmv · · Score: 2

    If you want to more assurance that your passwords aren't leaked to the internet don't install any other application with internet permission from the same developer. Two apps can share files if they are signed with the same key. The password application can still send the passwords to any other installed application using Intents too

  4. Re:Why even bother specifying INTERNET perms? by Seor+Jojoba · · Score: 2

    You know that sounds like a solid idea, but I scratch my head at the specific implementation of it. If you say that internet connections for ads are a separate permission, then would Google maintain a white list of ad providers? And then for ad providers, there'd need to be some policing to check that info going to the ad servers doesn't contain personal info.

    Maybe the way to handle it is to have a separate Android OS advertising API that manages the request sent to an ad provider, disallowing any possibility of sending app-specified info to the server. And then any ad provider that follows the protocol can be accessed via the advertising API with no risk of sending private info like what HTC is exposing.

  5. YES it is an OS issue by SuperKendall · · Score: 5, Insightful

    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.

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley
  6. Many reasons by SuperKendall · · Score: 2

    Why? It clearly isn't for ads, perhaps its for DLC???

    Even though I'm not sure exactly what Angry Birds on Android needs (aside from DLC which I know they do regularly), I can think of a lot of reasons why pretty much any game would want internet permissions:

    * Highscores
    * Achievements
    * Reduce level size on device
    * Tweeting to friends about game (yes, many games integrate with social networks).
    * web pages with game help material that you wanted to be able to keep more dynamic.
    * news feed for game users

    --
    "There is more worth loving than we have strength to love." - Brian Jay Stanley