Android libstagefright still exploitable • Hacker News Board

Re: Android libstagefright still exploitable

#131

Post by RexRollman » Thu, Aug 13, 2015, 9:24 PM UTC

chimeracoder wrote: post #101

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…

I think it is worst. As least with XP, you didn't have Dell preventing you from getting a security update.

Re: Android libstagefright still exploitable

#132

Post by Dylan16807 » Thu, Aug 13, 2015, 9:31 PM UTC

cautious_int wrote: post #106

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

I can understand the comparison passing, but why in the world does nothing warn about the truncation inside the new operator?

Re: Android libstagefright still exploitable

#133

Post by Dylan16807 » Thu, Aug 13, 2015, 9:37 PM UTC

matthewmacleod wrote: post #22

x0x0 wrote: post #16

Earlier quoted context omitted.

Eh, fuck google. They still haven't patched the original stagefright for android 4.4.4 on my nexus 5, and I don't want to upgrade to android 5, which I shouldn't be required to do to get security releases.

I shouldn't be required to do to get security releases. Why should you not be required to do that?

On an ethical level: Because there's quite a lot of difference between major versions, and you shouldn't be forced to replace one product with another to get basic fitness-for-purpose fixes on something that's only a year or two old.

On a practical level: Tons of devices are stuck on 4 and it's not hard to backport the fix. Once you do that, just compile it for the devices you sell already.

Re: Android libstagefright still exploitable

#134

Post by rodgerd » Thu, Aug 13, 2015, 9:45 PM UTC

matthewmacleod wrote: post #22

x0x0 wrote: post #16

Earlier quoted context omitted.

Eh, fuck google. They still haven't patched the original stagefright for android 4.4.4 on my nexus 5, and I don't want to upgrade to android 5, which I shouldn't be required to do to get security releases.

I shouldn't be required to do to get security releases. Why should you not be required to do that?

If Microsoft came out and said they weren't fixing a critical Windows 7 security flaw to force people to upgrade to Windows 10, HN would have bottomless wells of criticism. Google refuse to issue a security fix for a critical vulnerability for a less-than-2-year-old OS, and what, that's ok?

Re: Android libstagefright still exploitable

#135

Post by cautious_int » Thu, Aug 13, 2015, 9:46 PM UTC

Dylan16807 wrote: post #132

cautious_int wrote: post #106

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

I can understand the comparison passing, but why in the world does nothing warn about the truncation inside the new operator?

Because no truncation happens. In this case [] operator doesn't specify any type, only that the expression inside is an integer expression. While normally the type size_t is used for object and array sizes, [] takes any integer expression and the compiler won't complain.

Re: Android libstagefright still exploitable

#136

Post by NateLawson » Thu, Aug 13, 2015, 9:50 PM UTC

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…

The carriers are already blocking messages that match this pattern. That's why you haven't seen widespread exploitation.

https://twitter.com/jcase/status/628327791713517570

However, this only works in the US when you have 6 carriers. I have no idea what the situation is like elsewhere with massive carrier fragmentation.

Re: Android libstagefright still exploitable

#137

Post by NateLawson » Thu, Aug 13, 2015, 9:52 PM UTC

bitmapbrother wrote: post #111

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…

>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 minutes of being released in the wild? There are a couple of reasons: 1) Just because you have an exploit it doesn't guarantee you'll be able to execute code because you still need to bypass ASLR. The PoC's released do not do this. 2) Infecting phones with malware is very rare. Th…

Correct, most malware infections of mobile devices are targeted attacks for espionage etc.

Re: Android libstagefright still exploitable

#138

Post by NeutronBoy » Thu, Aug 13, 2015, 9:55 PM UTC

0xndc wrote: post #98

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…

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?

Re: Android libstagefright still exploitable

#139

Post by Dylan16807 » Thu, Aug 13, 2015, 10:01 PM UTC

cautious_int wrote: post #135

Dylan16807 wrote: post #132

Earlier quoted context omitted.

I can understand the comparison passing, but why in the world does nothing warn about the truncation inside the new operator?

Because no truncation happens. In this case [] operator doesn't specify any type, only that the expression inside is an integer expression. While normally the type size_t is used for object and array sizes, [] takes any integer expression and the compiler won't complain.

I'm talking about this line

  uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size];

size + chunk_size is clearly unsafe to truncate to 32 bits, but it truncates anyway. When I say 'inside the new operator' I'm including the allocation function. Something truncates it. If it actually allocated 8GB, or failed to allocate 8GB, there would be no exploit.

Re: Android libstagefright still exploitable

#140

Post by cautious_int » Thu, Aug 13, 2015, 10:26 PM UTC

Dylan16807 wrote: post #139

cautious_int wrote: post #135

Earlier quoted context omitted.

Because no truncation happens. In this case [] operator doesn't specify any type, only that the expression inside is an integer expression. While normally the type size_t is used for object and array sizes, [] takes any integer expression and the compiler won't complain.

I'm talking about this line uint8_t *buffer = new (std::nothrow) uint8_t[size + chunk_size]; size + chunk_size is clearly unsafe to truncate to 32 bits, but it truncates anyway. When I say 'inside the new operator' I'm including the allocation function. Something truncates it. If it actually allocated 8GB, or failed to allocate 8GB, there would be no exploit.

I was talking about the same line.

Apparently new is a "special" operator, or there is a bug in the compiler. I also can't get a warning with g++.

The problem seems to be that, as I said, [] takes any integer expression, it is there where the value gets truncated when operator sizeof or new is applied on it since they either return or take a size_t value.