Live data from Hacker News

Massive data stealing vulnerability found in many HTC Android phones

androidpolice.com

41–48 of 48 posts

Re: Massive data stealing vulnerability found in many HTC Android phones

#41

Does this issue allow me to close a 2 years contract with Orange before the end of the contract, without paying for the remaining months? I'm pretty sure that even if HTC fixes this mess I would have to wait forever for Orange to push the update with its custom sw.

Hopefully it does, but be ready to fight for it ;-)

Re: Massive data stealing vulnerability found in many HTC Android phones

#42
post #36

Earlier quoted context omitted.

Actually sometime back CM rejected patches that would allow you to prevent apps from collecting the device ID (which is obviously quite privacy invasive). I still run CM, but boy do I wish an open-source distribution would spring up that actually respects the phone's owner.

If I remember correctly the patch was rejected due to technical reasons, i.e. rejecting the device ID collection would cause the app to FC (force close) or render it unusable in most cases. You could try something like LBE Privacy Guard ( https://market.android.com/details?id=com.lbe.security ) which does let you deny permissions to installed apps, try denying the device ID to apps and see how many of them continue t…

Strange. I've used LBE Privacy Guard to block the device ID to loads of apps and have never seen it cause a force close. Doesn't it use per app device id forgery anyway?

Re: Massive data stealing vulnerability found in many HTC Android phones

#43
post #4

"Vulnerability" is an euphemism, this is a deliberately crafted backdoor. Perhaps it is a testing/debugging-facility that they forgot to remove from the production build? That'd be about the only semi-plausible excuse for HTC to come out of this alive (when/if mainstream media decides to jump on this).

Given that Google releases while most of its products are still in "beta". That seems very likely.

Re: Massive data stealing vulnerability found in many HTC Android phones

#44
post #11

I can't believe that somebody who is intelligent enough to write this application would miss such an obvious flaw. I literally can not conceive how it wouldn't have crossed their mind that any local app with network permissions would be able to connect to it. Were they just being lazy? Or were they forced to do it this way by some ignorant manager? I would love to hear how this happened.

It's likely debugging utils that were missed when readying for release.

Hmmm just like the "bug" in the data collection software in Google's streetview cars.

Re: Massive data stealing vulnerability found in many HTC Android phones

#45
post #4

"Vulnerability" is an euphemism, this is a deliberately crafted backdoor. Perhaps it is a testing/debugging-facility that they forgot to remove from the production build? That'd be about the only semi-plausible excuse for HTC to come out of this alive (when/if mainstream media decides to jump on this).

it depends, on the java side if we are using log.Config correctly and proguard right all logging is defanged and left out of any obfuscated application.

However, on the OS side it depends on what changes HTC made for carriers and how adequate their codeqa testing and security audits were

Re: Massive data stealing vulnerability found in many HTC Android phones

#46
post #14

How many of these phones are going to get a patch or updated firmware to fix this problem? I'm going to guess either very few or none, as most people won't notice/care about this issue, and HTC isn't making any money off supplying updates. Imagine if Microsoft forced Dell, HP, etc. to handle software security and updates on Windows for PC's they've already sold - it would either never happen or not happen correctly.…

alternate firmware

That's fine for personal use many companies strictly prohibit employees from using unauthorized software. You're pretty much stuck with whatever they give you.

Re: Massive data stealing vulnerability found in many HTC Android phones

#47

I can't believe that somebody who is intelligent enough to write this application would miss such an obvious flaw. I literally can not conceive how it wouldn't have crossed their mind that any local app with network permissions would be able to connect to it. Were they just being lazy? Or were they forced to do it this way by some ignorant manager? I would love to hear how this happened.

Probably outsourced it to a company that doesn't care.

Re: Massive data stealing vulnerability found in many HTC Android phones

#48
post #36

Earlier quoted context omitted.

Actually sometime back CM rejected patches that would allow you to prevent apps from collecting the device ID (which is obviously quite privacy invasive). I still run CM, but boy do I wish an open-source distribution would spring up that actually respects the phone's owner.

If I remember correctly the patch was rejected due to technical reasons, i.e. rejecting the device ID collection would cause the app to FC (force close) or render it unusable in most cases. You could try something like LBE Privacy Guard ( https://market.android.com/details?id=com.lbe.security ) which does let you deny permissions to installed apps, try denying the device ID to apps and see how many of them continue t…

The first submitted patch (of the saga) returned a randomly generated ID (which wouldn't cause crashes). It was rejected in order to "not upset app developers". I can see why Google would never accept such a patch into mainline, but such a status-quo kowtow by an 'independent' project astounds me.

I'll have to look into LBEPG and see if it actually fixes this. I had poked around a bit and it seemed painful to implement this kind of functionality in an app, but perhaps they've found a way (or are playing some really invasive games with system libraries).

Post reply on HN