Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android libstagefright still exploitable

blog.exodusintel.com

Post reply on HN
Print view View original

101–110 of 150 posts

Re: Android libstagefright still exploitable

#101

Post by chimeracoder »

RexRollman wrote: post #99

IMO, the Android echosystem is a clusterfuck and Google needs to get a hold of it. I would buy a Windows phone before I would buy an Android device.

> IMO, the Android echosystem is a clusterfuck and Google needs to get a hold of it. I would buy a Windows phone before I would buy an Android device.

This is nowhere near as bad as the situation with Windows XP 10 years ago.

The difference is that Android has the majority marketshare worldwide and Windows phone does not, making Android the more attractive target both for researchers and malicious actors.

Security by obscurity is not entirely without value, but it's not particularly strong as a defense either.

Re: Android libstagefright still exploitable

#102

Post by pacquiao882 »

scintill76 wrote: post #90
semenko wrote: post #58

Earlier quoted context omitted.

The isolation seems mostly defined by this SELinux policy: https://github.com/android/platform_system_core/blob/lollipo... service media /system/bin/mediaserver class main user media group audio camera inet net_bt net_bt_admin net_bw_acct drmrpc mediadrm ioprio rt 4 You'd need another exploit to elevate from SELinux (and I think send MSSes for a self-propagating worm). Though given Android's abysmal patching, most An…

I could have sworn I read in the OP a few minutes ago, that mediaserver runs as "system" on some devices, which would probably be worse. I'm not finding it now, so maybe it was edited or I'm mis-remembering. Anyway, vendor customization diverging from AOSP makes it hard to say.

You are correct. It runs with system and graphics privileges on many devices. It is a native service started at system init and is automatically restarted if it crashes.

Re: Android libstagefright still exploitable

#103

Post by nissehulth »

ryandvm wrote: post #100
stevenh wrote: post #72

Any competent malware developer must have already figured out how to exploit this the first time around. Now that every single one of those malware developers has learned it is still exploitable, the payload they've spent the past month perfecting can now be deployed in the wild. So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten m…

It's not often that Android's fragmentation is touted as a benefit, but the fact that Android isn't a monoculture is certainly one of the hurdles to developing a worm capable of mass deployment. Supposedly the varying implementations of the Android media services mean a libstragefright exploit may or may not end up with root access. Now, if this were an iOS zero-day exploit... [Actually, it'd be trivial for the carri…

Yes, I believe the payload have to be tailored pretty much exclusively for each type of device. But, I doubt that would stop anyone trying. Company phones are often the same type and model, someone with a certain target in mind could probably put in the hours.

Re: Android libstagefright still exploitable

#104

Post by eropple »

ocdtrekkie wrote: post #51
eropple wrote: post #41

Earlier quoted context omitted.

I feel for people whose providers won't upgrade them and I think they've got a good complaint, but if you choose to get off the upgrade path I think it's reasonable to assert that you're assuming responsibility for your own choices and security. I expect it can be backported to 4.x via custom ROMs for folks in that spot.

Here's the problem: It's a DROID Turbo. It's locked down by Verizon/Motorola, and neither root nor bootloader unlock has been achieved. So it's not even an option. The problem is that the "upgrade path" and the "security fix" path need to be separate things. People should not be forced to have their device changed in an unacceptable manner (I did not buy a device with 'material design' for a reason, and being forced…

I think, honestly, the only real answer is "don't buy locked devices if you want to make those choices." Google doesn't control those devices, and that part of Android is open source. You can make those decisions, but you're earning the consequences with them.

This, as it happens, is why I buy phones with unlockable bootloaders. My current phone uses the OEM build, but I like having that choice.

Re: Android libstagefright still exploitable

#105

Post by eropple »

ocdtrekkie wrote: post #91
cwyers wrote: post #89

Earlier quoted context omitted.

I agree that DEVICES should be covered for n years, where n is somewhere between 3 and 5 and we can quibble about the specifics later. I don't think that backporting fixes should be the way we gauge this if newer versions are available instead.

The problem is that newer and better are not synonymous. And most Android users have probably learned by now that their devices getting slower with each update, not faster.

Mine are getting no slower and often feel snappier. 5.1 was a big improvement over 5.0 on my Z3C.

Re: Android libstagefright still exploitable

#106

Post by cautious_int »

This is a common problem in C. Integer types are inherently type unsafe and are silently promoted with many different rules which are hard to remember and understand. As is seen in this case, even the ( borderline paranoid ) flag -Wconversion would not catch the bug.

I think this problem in C would be solved with a single flag: -Wwarn-if-using-integers-of-different-types-in-an-operation , forcing you to cast the integer if the types don't match in a arithmetic operation, or an assignment.

Re: Android libstagefright still exploitable

#107

Post by ocdtrekkie »

eropple wrote: post #104
ocdtrekkie wrote: post #51

Earlier quoted context omitted.

Here's the problem: It's a DROID Turbo. It's locked down by Verizon/Motorola, and neither root nor bootloader unlock has been achieved. So it's not even an option. The problem is that the "upgrade path" and the "security fix" path need to be separate things. People should not be forced to have their device changed in an unacceptable manner (I did not buy a device with 'material design' for a reason, and being forced…

I think, honestly, the only real answer is "don't buy locked devices if you want to make those choices." Google doesn't control those devices, and that part of Android is open source. You can make those decisions, but you're earning the consequences with them. This, as it happens, is why I buy phones with unlockable bootloaders. My current phone uses the OEM build, but I like having that choice.

Google :does: control those devices. They're MADA agreement devices, which means Google approves every device that goes to sale, and Google approves every software update they release.

Unfortunately, as a Verizon customer, I don't have a wide variety of options with unlockable bootloaders. And the battery life on the Turbo was simply, the only feature that mattered. Usually there's an unlock within a few months, but there still isn't one at this point for the Turbo, I guess.

Re: Android libstagefright still exploitable

#108

Post by pokpokpok »

ryandvm wrote: post #100
stevenh wrote: post #72

Any competent malware developer must have already figured out how to exploit this the first time around. Now that every single one of those malware developers has learned it is still exploitable, the payload they've spent the past month perfecting can now be deployed in the wild. So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten m…

It's not often that Android's fragmentation is touted as a benefit, but the fact that Android isn't a monoculture is certainly one of the hurdles to developing a worm capable of mass deployment. Supposedly the varying implementations of the Android media services mean a libstragefright exploit may or may not end up with root access. Now, if this were an iOS zero-day exploit... [Actually, it'd be trivial for the carri…

do carriers already have a mechanic in place to trigger precautions a message matching worm-like patterns (similarity, mass transmission)? or would they have to implement one after it's too late?

Re: Android libstagefright still exploitable

#109

Post by nadams »

jeffreyparker wrote: post #95
nadams wrote: post #69

Earlier quoted context omitted.

> Even if Google patches this, there's an incredible delay in getting the patch to users. I don't think delay is the problem - not being able to get or apply the patch yourself is the problem. Ignoring the somewhat ridiculous requirements to compile Android (200GB of HD space and 16GB of RAM [1]) - you couldn't put it on your Android device due to proprietary drivers for wireless and/or video. Assuming you can get an…

Regarding exporting OTP settings: My solution was to use Titanium Backup on the Google Authenticator app, extract secret keys from that data, use them to create GA-compatible setup QR codes for each account, and save those QR codes in KeePass. You could likely do something similar with FreeOTP, once that's done you can easily restore your codes without root. (And from then on be sure to save any future setup QR codes…

I backup my keys into keepass just like you - but I would have to restore about 20 OTP accounts. Not something I want to do more than once.

And this is a workaround for a lack of a feature rather than a solution.

Also - I didn't say that was the only reason why I wanted root :).

Re: Android libstagefright still exploitable

#110

Post by acdha »

stevenh wrote: post #72

Any competent malware developer must have already figured out how to exploit this the first time around. Now that every single one of those malware developers has learned it is still exploitable, the payload they've spent the past month perfecting can now be deployed in the wild. So, can someone explain why a disastrous worm hasn't already swept the globe and infected 99% of Android devices on the planet within ten m…

I suspect the answer is something like this:

1. A worm would be highly visible and easily blocked by carriers

2. There's no easy way to make more money from a mass worm than you could make from lower-profile, more-targeted attacks. You could ask a billion people to send you a dollar but that'd leave a paper trail anyone could follow.

3. The more widespread it is, the more pressure there is on vendors & carriers to ship patches for old devices

Post reply on HN