Massive data stealing vulnerability found in many HTC Android phones | Hacker News Reader

Massive data stealing vulnerability found in many HTC Android phones

androidpolice.com

169 pointsarchon81044 comments

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. Swap the players and that's where Android is today.

(yes, I know about alternate firmware - how many non-geeks are capable of using it and have devices that don't have technological blocks like signed bootloaders to prevent it?)

One of the affected models, the Thunderbolt, only now started getting updates to Gingerbread this week. That is, until Verizon halted it due to a major usability bug that should have been identified easily in carrier testing (voicemail notifications don't work).

Given that it took it took HTC this long to get an update to an Android version that's been available in source since December and they still managed to mess it up, I don't have high hopes for something like this getting fixed.

Surely the blame there is on Verizon. My aging, carrier-free HTC Nexus One gets regular updates.

There are only two ways I recommend Android - use a Google-branded phone that Google will provide complete OS support for, or go it alone with OS updates from a 3rd party.

For non-geeks the first option is the only viable one, IMHO.

You've obviously settled on the same conclusion.

Could you point me in the right direction for 3rd party?

I guess zdw is referring to Cyanogenmod. There might be others, I don't know.

On my (contractless) Galaxy S2 - OTA updates happen never, I have to connect to a Windows box for updates.

Do you know how OTA updates are pushed out for the non-Google Android phones that are bought without a contract?

How well they manage android version bumps has nothing to do with security updates.

Thats why I love the Windows Phone and Apple model rather than android. Windows Phone has had more and frequent updates and they are delivered more consistently across carriers. Same is true for Apple.

Apple, yes. Windows Phone, seriously? The same Windows Phone which resulted in bricked phones after the NoDo update.

Windows Phone has the same update model as Android. You need manufacturer and carrier compliance for an update to get to a phone. Plus there is no custom ROM alternative like with Android. http://www.winsupersite.com/article/windows-7/Windows-Phone-...

Despite the brain-dead implementation that's the cause of this privacy fiasco, HTC has the best track record among Android manufacturers when it comes to releasing updates. So I would hope they address this issue, and fast.

http://androidandme.com/2011/08/news/updates-or-lack-thereof...

Windows Phone is an infant platform as compared to Apple and Android. But yet look at how fast they learnt after the NoDo delays. Have you gotten the Mango update yet? It rolled out to exsting phones already. And that is not just in US but worldwide. How many updates has Android pushed so soon to its existing phones and that too so widely?

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.

Can we word that differently?

"Imagine if Dell, HP, etc forced Microsoft to let them handle software security and updates on Windows for PCs they've already sold..."

Last I checked, Google isn't volunteering to manage all aspects of Android OS updates for the device vendors (as MS does for Windows), so I don't think the reversal is valid.

Google would get nothing but more work and responsibility out of such an arrangement.

Yes, it would be better for security and end users, but who cares about them? Google is in it for the ad revenue, and the HW vendors are in it to sell units, not have old models with new software compete against their new hardware.

"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

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

This is an awesome reason to root your phone the second you get it. I've done so to both of my Android phones. You know that cyanogenmod is safe from this kind of blatant wiretapping, and on top of that, you don't have to worry about hassling with it when you need to tether, or when you want to install an application that requires root permissions to function well. :)

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 to work. I have, and not many do.

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

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?

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.

Mmm, I don't know. I'm going to vote for ignorant management.

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

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

Android is not having a good time with security this week. The Samsung Galaxy S II on AT&T is very easy to unlock without the PIN or password. http://www.bgr.com/2011/09/30/major-security-flaw-lets-anyon...

These issues are manufacturer dependent and not Android issues.

They are issues for Android the brand.

And for Google's practice of letting manufacturers do whatever bloody stupid thing they want. I'm stunned that this one ever got into production in its current state.

> They are issues for Linux the brand.

> And for Linus's practice of letting distributions do > whatever bloody stupid thing they want. I'm stunned that > this one ever got into production in its current state.

Fixed that for you.

Sure, I was just talking about reputation.

Which is why I am glad I got a firewall on my phone and whitelist selected applications to have internet access.

You should read the article. Apparently any app that you give permission to use the Internet can leak all your data. Are you absolutely positive that every single free app you download is safe?

I only let apps I trust access the internet.

At least with droidwall, non-whitelisted apps are perfectly able to connect to local ports (in fact I've got a few apps that don't get internet access, and instead get ssh port forwards).

And it looks like (at least on CM) non-whitelisted apps can make DNS queries as well (so they can still send the data home).

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

I think security risk could be used as a reason to favor web apps over native apps. An untrusted native app has the potential to do much more damage than an untrusted web app.

One more reason that I'm awfully glad I'm running CyanogenMod on my Sensation.

This is the very reason I smashed my iPhone and do not keep a mobile phone on me anymore. Call me paranoid but I'm enjoying life far more without it burning a proverbial hole in my pocket.

The reason you smashed your iPhone is because HTC software has an overly detailed and insecure logging suite?

I call you not overly paranoid, but maybe bizarrely superstitious?

It's true that there's always risk involved with advancing technology. Faster, better and more capable phones are better at doing good things for you, but it also makes them more capable of doing bad things to you too.

Reply on news.ycombinator.com