• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Android security breach lets apps get around permissions

Interesting read, thanks for posting.

If I follow what they are saying, mostly the case hinges on a feature of Android apps called a sharedUserID. This allows a company to write apps that share resources, permission and other stuff by running under the same Linux process.

Here's the link to the PDF for those who would like to bypass the sensational article ;)

http://www.csc.ncsu.edu/faculty/jiang/pubs/NDSS12_WOODPECKER.pdf

This is not a bug in the OS itself but rather carrier/manufacturer apps that carelessly make use of the feature. However, I am tired at the moment and was only able to give the paper (PDF) linked in the article a quick read. I'll have to try and find some time to check it more thoroughly.
 
So the culprit is carrier/manufacturer apps is it? There is nothing we can do except to root and remove them is it? But root void warranty isn't it? No wonder they can sell those smart-phones cheap + plan.
 
So the culprit is carrier/manufacturer apps is it? There is nothing we can do except to root and remove them is it? But root void warranty isn't it? No wonder they can sell those smart-phones cheap + plan.

It also includes the official Google apps and the frameworks that Google built into the OS. So just flashing vanilla Android will not solve this problem, until Google fixes it. But the biggest culprits are manufacturers and carriers.
 
It also includes the official Google apps and the frameworks that Google built into the OS. So just flashing vanilla Android will not solve this problem, until Google fixes it. But the biggest culprits are manufacturers and carriers.


Only one official app, I saw no mention of framework problems.

The official app was the pico TTS app, and the only malicious thing they were able to get it to do was to uninstall a different unrelated part of the TTS apps.

At least that's how I read it.
 
I was thinking does Google provide some proprietary API that is meant only to be used by carrier and manufacturers ? This is so unfair to us developers. We are blocked from using those API ?
 
not proprietary per-say but Carriers and Manufacturers have always had the ability to mark their own add-ons as "system" apps giving them access to the more dangerous permissions.

The problem comes when they also use the "sharedUserId" feature, and do not sanitize inputs or perform security checks.

Basically a hacker could construct a malicious app that ran as a regular app, but used the same sharedUserId and spoofed the signature of the carrier app, then it would gain access to any permissions the carrier app has.

again though I read that security paper at like 4am last night so I was a bit blurry eyed. I may not be getting the whole picture here heh.
 
What I also found interesting about this paper though, is that these guys have basically coded a tool to help look for such vunerabilities.

And while that sounds helpful to a hacker, it really helpful to a programmer at HTC or Samsung or Google (etc) to check and make sure he didn't accidentally leave a security whole.

Tools like this are actually very GOOD for security. They help the programmers auto-test some aspects of their code. Hopefully these guys will release the source code. I'm thinking of emailing/asking them.
 
Only one official app, I saw no mention of framework problems.

The official app was the pico TTS app, and the only malicious thing they were able to get it to do was to uninstall a different unrelated part of the TTS apps.

At least that's how I read it.

I could have sworn I read framework.res being stated as one of the spots with vulnerabilities. But that could have been the article, not the report.
 
Well yes and no, From what I understood, (which might not be correct) they were saying that framework.res has system level privileges, and when a carrier installs an app that is marked as "system" it can freely call dangerous permissions in framework.res.
 
At least they listed the suspected phones and where the threat was likely to be.

From my reading of it (unless I misunderstood), they just picked those particular phones in the list to test on...that is not a list of the "suspected phones"...from what I understood, this could be on every android device...
 
this could be on every android device...

From what I get it IS installed on virtually every Android device, but perhaps not activated by every carrier/manufacturer. Although they tumble over each other making statements that 'no, they (whoever is speaking) haven't activated it'!

But 1) I don't believe them, they have all lied before, and 2) if it isn't activated NOW, when will it be? I don't want spy software on my phone. Activated or not. Because as long as it is on my phone 'they' can activate it at will every second of the day, every day, always ! Without me having a clue.

It is also important to note, imo, that none of them deny that it is installed on 'their' phones. 'We haven't activated it' (whether true or not) is of course the lamest of 'defenses'. It's like saying to your better half "Yes, honey, that is indeed strychnine, and I got it to be able to poison you, but why are you so upset? I didn't actually use it, did I"?

On the bright side (for some): this rootkit is also installed in iOS. And Apple also says they 'haven't activated it'...

Yeah, right.

Carrier IQ references discovered in Apple's iOS | The Verge
 
@ Rovers, this particular topic is not related to Carrier IQ.

However I do believe this problem exists on most devices. However, again this is more of a failing of the pre-installed apps, and letting them be marked system. Then they have to make a specific mistake related to sharing resources and permissions between more than one of their apps.

While this is cause for concern, it's relatively easily fixed as far as I can tell....
 
This is getting ridiculous. First carrierIQ and now this. Android is not getting good press lately.
 
Back
Top Bottom