Live data from Hacker News

Android libstagefright still exploitable

blog.exodusintel.com

91–100 of 150 posts

Re: Android libstagefright still exploitable

#91
post #89

Earlier quoted context omitted.

The fact that Google created a huge maintenance burden for themselves shouldn't absolve them of responsibility to provide that maintenance. Microsoft supports Windows versions for ten years, and I agree that's crazy for Android. However, three years I feel is a bare minimum expectation. Devices tend to remain on the market for about a year, and the standard phone contract is two years. So three years from a version r…

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.

Re: Android libstagefright still exploitable

#92
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…

That's not an SELinux policy? That's just a service statement for Android's init, defining the process' supplementary groups. There is no explicit seclabel I can deduce.

The policy is linked. The service definition was probably quoted to show other aspects of its isolation and privileges, but the comment is not written very clearly.

Re: Android libstagefright still exploitable

#93
I think the proper check is:

// size_t size; // uint64_t chunk_size;

if (chunk_size >= SIZE_MAX - size) { return ERROR_MALFORMED; }

Due to size being a size_t and SIZE_MAX being well a maximum size_t, SIZE_MAX-size is properly calculated. The comparison with chunk_size is also properly done (due to the C promotion rules - as strange as they are, they do work "as expected" when your values are nonnegative, which they are here).

Also, I am slightly puzzled why one would use SIZE_MAX as a limit rather than some "small" number, like a few megabytes or whatever is a reasonable bound for this buffer. In this case the fix may be a bit more complex than this: if (chunk_size >= SIZE_MAX - size || size + chunk_size > the_limit) .

Re: Android libstagefright still exploitable

#94
post #57

Earlier quoted context omitted.

It's not an apples-to-apples comparison, but Android has been around since 2007, and they're up to API level 22 right now. In that same time period, Microsoft has had the following releases of Windows (excluding Mobile/Phone and Server): Vista, which actually came out in 2006 in the OEM edition Windows 7 Windows 8 Windows 8.1 Windows 10 Windows has had a much slower release cadence than Android. It's a much, much big…

(That said, every time I read an article about Android these days I get the urge to buy a Windows Phone.) I just did that two days ago, the update situation being one of the reasons (the other that I like a reasonable quality dual SIM phone). For now, it's just an extra phone to play with (Lumia 640, cheap, great build quality/performance for the price). But who knows ;).

I have a Lumia 635, which is nice "for the price" I agree but not nice enough to switch to full-time. I'm hopeful that the new high-end phones provide a real choice.

Re: Android libstagefright still exploitable

#95
post #69

Even if Google patches this, there's an incredible delay in getting the patch to users. Android in fundamentally flawed in this respect. http://www.extremetech.com/mobile/197346-google-throws-nearl...

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

Re: Android libstagefright still exploitable

#96
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…

From what I've read, and could be wrong, is you could be infected and not even know it. The attacker has the opportunity to "clean up" the MMS so you never even get a notification because the bug is before any of that kicks in.

Re: Android libstagefright still exploitable

#97

Even if Google patches this, there's an incredible delay in getting the patch to users. Android in fundamentally flawed in this respect. http://www.extremetech.com/mobile/197346-google-throws-nearl...

This was one of the big motivating factors for me getting a nexus 6 (aside from the size) and putting it on the fi network. I got 2 updates in the period of a week.

I think the problem is vendors and carriers wanting to modify and inject their crapware and custom UIs into Android. Google is happy to provide upgrades to the OS in a timely fashion (and are going to start monthly updates), it's the vendors/carriers that delay these updates or don't even bother to port them over to devices.

Google is moving much of the core Android functionality over to specific apps that they can update as needed from the play store, instead of integrating them directly into the OS. This is good, because it allows them to push the updates quicker. They run the risk that carriers will get sick of the lack of control over the "experience" they can provide, and fork android, but it's a necessary step in many ways to ensure things like this MMS exploit can be patched on some devices at all, as vendors abandon some phones quickly, leaving users vulnerable.

If every vendor and carrier used stock nexus android without modification, the updates could be pushed out in days. The linked article blames google for these problems, but that is, in my opinion, misguided.

Re: Android libstagefright still exploitable

#98
post #69

Even if Google patches this, there's an incredible delay in getting the patch to users. Android in fundamentally flawed in this respect. http://www.extremetech.com/mobile/197346-google-throws-nearl...

> 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…

It's a check - as of Android 5.0, Google's OTA updater scripts refuse to overwrite your /system partition if its checksum isn't on the known-good list. Rooting inevitably involves writing files to it, so OTA updates will stop working with an uninformative "Error!" in recovery. Whoever came up with the idea should be fired, but that's Google for you.

See [1] for details from the author of NRT [2], which can update your phone from factory images without wiping it. The procedure is a bit more involved if you're not on Windows - IIRC, you have to download the correct archive from [3] and modify the update script so it doesn't try to flash userdata.

[1] http://www.wugfresh.com/faqs/can-i-still-take-an-ota-after-i... [2] http://www.wugfresh.com/nrt/ [3] https://developers.google.com/android/nexus/images

Re: Android libstagefright still exploitable

#100
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 carriers to filter the payload, so I don't reckon SMS/MMS is ever going to be a viable transmission vector.]

Post reply on HN