http://www.cyanogenmod.org/blog/more-stagefright
Looks like Cyanogenmod has patched this toot-sweet.
Android libstagefright still exploitable
141–150 of 150 posts
Re: Android libstagefright still exploitable
#142Earlier quoted context omitted.
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.
Still, we'd see a bunch of reports from non-Android phones receiving MMS's from infected Android contacts.
I've received an MMS unexpectedly from one of my contacts. (I'm on Android)
Re: Android libstagefright still exploitable
#143Earlier quoted context omitted.
Didn't a number of texting apps, possibly including hangouts, update to fix it separate of this botched fix? EDIT: I just checked and sure enough my texting app, QKSMS, updated to remove the Stagefright library
No, apps cannot remove system libraries responsible for processing video. What your MMS app did was disable the auto-retrieval of MMS messages.
It can't remove the system libraries, but it can decide not to use them. Yes, this means if you were to open it with any app that isn't protected then you will still be vulnerable, but within the app you're safe.
Source: I wrote QKSMS
Re: Android libstagefright still exploitable
#144Things like this is why I trust an iPhone enough to handle two-factor auth for banking (in Sweden: "Mobil BankId"), but not an Android device. I hope Google will raise the security level now that they have reached global dominance, in no small part through lax security (as a consequence to their liberal licensing models).
Security through obscurity is no security at all.
Re: Android libstagefright still exploitable
#145Earlier quoted context omitted.
There's a performance cost now because processor instruction sets have dropped hardware overflow detection due to disuse. Current processors are largely engineered to just run legacy C code fast. See eg. https://news.ycombinator.com/item?id=7847980
No, overflow is still properly detected by common CPU instructions. There are flags that are set on overflow after the addition and subtraction and they can be tested. It's only hard to test the flags in "standard" C (I don't know if it's better with newer standards or those in progress) but the CPUs do their work on the hardware level.
But like ploxiln said you now need a conditional branch to test for the overflow flag after the arithemetic operation, unlike the old overflow traps on x86/MIPS/Alpha etc.
Re: Android libstagefright still exploitable
#146Earlier quoted context omitted.
(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.
But there is quite a difference between the 635 and the 640: non-HD vs. HD, possibly 512 MB RAM (depending on the version) vs. 1 GB RAM, 5MP vs. 8MP camera.
I agree that new flagships would be nice though. Especially with Continuum.
Re: Android libstagefright still exploitable
#147Re: Android libstagefright still exploitable
#148Earlier quoted context omitted.
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 you…
> Whoever came up with the idea should be fired, but that's Google for you. To be fair to Google, once you've modified your /system partition, it's really case-by-case how an update will interact with it. The alternative is Google push an update that inadvertently bricks a bunch of rooted phones. Can you imagine the kneejerk reaction from the internet then?
> The alternative is Google push an update that inadvertently bricks a bunch of rooted phones. Can you imagine the kneejerk reaction from the internet then?
That already happens [1] on non-modified devices. So just come up with a "yes I know what I'm doing and accept that this may bork my phone". Or and even better idea - how about the ability to turn off OTA updates? Right now my phone says there is an update but I can't apply it due to being rooted.
[1] http://www.techtimes.com/articles/51525/20150508/nexus-9-and...
Re: Android libstagefright still exploitable
#149Earlier quoted context omitted.
No, overflow is still properly detected by common CPU instructions. There are flags that are set on overflow after the addition and subtraction and they can be tested. It's only hard to test the flags in "standard" C (I don't know if it's better with newer standards or those in progress) but the CPUs do their work on the hardware level.
But like ploxiln said you now need a conditional branch to test for the overflow flag after the arithemetic operation, unlike the old overflow traps on x86/MIPS/Alpha etc.
I'm not aware that integer operations ever made traps on x86 and nobody actually uses floats for allocation sizes (in C). And checking the flag would be more than enough IF the languages supported it.
It's the languages that should be changed to be able to simply check the overflow after the critical operations, not the CPUs. The overflow checks are needed only where something can "go wrong" not everywhere.
Re: Android libstagefright still exploitable
#150Earlier quoted context omitted.
Didn't a number of texting apps, possibly including hangouts, update to fix it separate of this botched fix? EDIT: I just checked and sure enough my texting app, QKSMS, updated to remove the Stagefright library
No, apps cannot remove system libraries responsible for processing video. What your MMS app did was disable the auto-retrieval of MMS messages.
Uh no, it disable the stagefright library... disabling MMS auto-retrial is something else that I also did, but QKSMS also removed the ability for the app to interface with the Stagefright Libraries