Live data from Hacker News

Android libstagefright still exploitable

blog.exodusintel.com

31–40 of 150 posts

Re: Android libstagefright still exploitable

#31
Why are arithmetic overflows and underflows not exceptions/crashes by default, like divison by 0?

Aren't the cases where you actually want an over/underflow the exception? Why not resort to special instructions/macros/operators for these operations?

Re: Android libstagefright still exploitable

#32

Earlier quoted context omitted.

Can you help me understand this? They're complaining about a bug in the patch implementation and the patch implementation did not exist prior to the patch; ergo, if Google didn't patch the code, they wouldn't be able to write the article. Is that not a new bug almost definitionally? Please help me understand if I am incorrect. I understand the underlying issue which was first reported did not get patched properly, bu…

What? If your intention is to apoligize Google, can you do it in a more clear way?

I'm not a Google apologist and I don't appreciate your tone. I'm attempting to orient myself so that I can think about what is right and wrong with respect to responsible disclosure in a clear and coherent fashion.

Re: Android libstagefright still exploitable

#33

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

Indeed. Even the supposedly quickly updated Moto X did not receive a patch yet two weeks after the fact [1]. I feel sorry for all those people who are still stuck on Kit Kat or even worse Jelly Bean.

https://www.reddit.com/r/MotoX/comments/3gugxa/anyone_got_th...

Re: Android libstagefright still exploitable

#34

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

Agreed. There is a major issue, not sure if in the rest of the world, but in Canada, the service provider has to request, and commonly pay for, the patch to which the manufacturer completes and then the service provider then pushes out to their devices. At least that is how it was when the E911 issue happened, it may be better now, but knowing Telecoms in Canada, I wouldn't be surprised if it wasn't.

It's not better. Look at the proposed target released dates for StageFright patches by Telus. And considering that it is not even fully patches, this only adds to the insanity of the situation with regards to Android fragmentation and carrier's controlling releases.

http://forum.telus.com/thread/54211/category/top/board/Mobil...

  OEM	 	Model	 	        Target Release
  HTC           One M7	 	        August 14th
  HTC	 	One M8	 	        August 14th
  HTC           One M9	 	        August 14th
  HTC           Desire 320a	        August 28th
  HTC           Desire 601	        August 14th
  LG	 	Nexus 4	 	        Completed
  LG	 	Nexus 5	 	        Completed
  Motorola	Nexus 6	 	        Completed
  Samsung	Galaxy S5	 	August 11th
  SamsungGalaxy S5 Active	 	August 11th
  Samsung	Galaxy Alpha	 	August 21st
  Samsung	Galaxy Grand Prime	August 21st
  Samsung	Galaxy S6	 	Completed
  Samsung	Galaxy S6 Edge	 	Completed
  Samsung	Galaxy S4	 	August 28th
  Samsung	Galaxy Note 3	 	August 30th
  Samsung	Galaxy Note 4	 	August 11th
  Samsung	Galaxy Core	 	September 4th
  Samsung	Galaxy Tab S 8.4	September 4th
  Samsung	Galaxy Tab S 10.5	September 4th
  Sony	 	Xperia Z3	 	August 14th

Re: Android libstagefright still exploitable

#35

And I was wondering at the beginning of the article why they were doing if (SIZE_MAX - chunk_size and not the more readable if (size + chunk_size >= SIZE_MAX) Of course, C integer overflow. The real WTF is that this is possible in C. What would be more sensible than integer overflow would be to automatically promote integers to a larger type in the context of a comparison, so that they don't overflow. I wonder if you…

You seem to be asking for quite some magic in that __no_overflow idea. It might be possible with a trivial expression like this, but what if there are function calls in that expression, or even library calls? There are lots of places overflow could happen, and the site of your __no_overflow may not have code-gen control over it at all.

As for __checked, gcc has some builtins like this: https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...

Re: Android libstagefright still exploitable

#36

And I was wondering at the beginning of the article why they were doing if (SIZE_MAX - chunk_size and not the more readable if (size + chunk_size >= SIZE_MAX) Of course, C integer overflow. The real WTF is that this is possible in C. What would be more sensible than integer overflow would be to automatically promote integers to a larger type in the context of a comparison, so that they don't overflow. I wonder if you…

[deleted]

Re: Android libstagefright still exploitable

#37
post #4

>Deadline exceeded – automatically derestricting >The flaw was initially reported over 120 days ago to Google, which exceeds even their own 90-day disclosure deadline. It always seemed likely that Google's hubris[1] would come back to haunt them. I guess this is that day. It would be funny if it wasn't remote code execution affecting 950 million phones, with no official patch in sight. [1] https://news.ycombinator.co…

Wait, either I'm grossly misunderstanding the article, or you are. The flaw the author is talking about is one that Google has been aware of for six days... Not 120. The original bug from 120 days ago was already patched. We're essentially talking about a bug in the bugfix, which obviously hasn't existed as long as the original bug itself. I'm really not seeing where "hubris" comes into this.

That's the logic the blog author is using. As you can see in the bit of the article I quoted. I didn't say I necessarily agree with their analysis of this still being the same bug.

The fact that they mentioned it a couple of times suggests it was a factor in their decision to release the details today (or at least wanted to poke fun at Google).

Re: Android libstagefright still exploitable

#38

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

Indeed. Even the supposedly quickly updated Moto X did not receive a patch yet two weeks after the fact [1]. I feel sorry for all those people who are still stuck on Kit Kat or even worse Jelly Bean. https://www.reddit.com/r/MotoX/comments/3gugxa/anyone_got_th...

And for those of us who don't want Lollipop, we'll never be offered the update. We have to either accept a bad system "upgrade" or stay insecure.

Re: Android libstagefright still exploitable

#39

Summary: A little over two weeks ago, it was publicly disclosed that MMS messages can cause Android phones to decode video with libstagefright, which is a C++ library with vulnerabilities and insufficient sandboxing, leading to remote code execution without user interaction. Today, Exodus Intelligence is reporting that the patch to fix one of these vulnerabilities does not, in fact, fix it. Thus, all Android phones a…

This specific exploit can be initiated whenever metadata for an MP4 file is processed. Disabling auto-download of MMS is an important first step workaround. Be cautious with any untrusted media files on your Android device. Simply creating the thumbnail preview image is enough to silently trigger privileged code execution.

Re: Android libstagefright still exploitable

#40

Summary: A little over two weeks ago, it was publicly disclosed that MMS messages can cause Android phones to decode video with libstagefright, which is a C++ library with vulnerabilities and insufficient sandboxing, leading to remote code execution without user interaction. Today, Exodus Intelligence is reporting that the patch to fix one of these vulnerabilities does not, in fact, fix it. Thus, all Android phones a…

I'm still unclear on the sandboxing assertion. The mediaserver in current versions is, in fact, pretty well isolated. I've had to work around and defeat lots of this protection for debugging purposes in my professional life, so I know it's there. IIRC you can't read system or app data outside the sdcard area, you can't write anywhere persistent. You can open network sockets and make binder requests, which is not trivial but again rather different from a remote root.

That this is an exploitable bug in libstagefright seems to be uncontested. But AFAICT there are no assertions of an actual sandbox breakout or a practical payload that does something more than e.g. send spam. Are there? Link?

Post reply on HN