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

21–30 of 150 posts

Re: Android libstagefright still exploitable

#21

Post by ocdtrekkie »

x0x0 wrote: post #16
josh2600 wrote: post #2

Did I read that right? They reported the bug to Google on August 7th and disclosed it publicly on August 13th? Is this still responsible disclosure if they give Google basically 6 days to respond and use the original notification date as justification? I'm not learned enough in the practice of responsible disclosure to know if this is common, but I've not seen that before.

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.

Same problem. My options for my Droid Turbo are suffer Android 5.x or get a Windows Phone.

...I'm getting a Windows Phone.

Re: Android libstagefright still exploitable

#22

Post by matthewmacleod »

x0x0 wrote: post #16
josh2600 wrote: post #2

Did I read that right? They reported the bug to Google on August 7th and disclosed it publicly on August 13th? Is this still responsible disclosure if they give Google basically 6 days to respond and use the original notification date as justification? I'm not learned enough in the practice of responsible disclosure to know if this is common, but I've not seen that before.

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?

Re: Android libstagefright still exploitable

#23

Post by roblabla »

josh2600 wrote: post #15
jimrandomh wrote: post #10

Earlier quoted context omitted.

It isn't a new bug; what they're reporting is that the patch which was supposed to fix an already-publicly-disclosed bug doesn't fully fix it.

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…

Keeping it secret wouldn't have been very useful. The original issue was already well-known, and seeing the severity and media-exposure of the bug, it is very possible malicious actors studied the patch and independently found out about the problem that came with it. At this point, it is better to let the public at large know they are at risk than let the skiddies have fun with this pseudo-0-day.

Re: Android libstagefright still exploitable

#24

Post by MichaelGG »

hoopism wrote: post #9

Is this timeline correct? April 2015 - Original stagefright exposed July 31st - Author noticed patch was not sufficient but could not test (did not notify google) August 6th - Patch released August 7th - Author notified google that patch was not adequate August 13th - Author went public?!?! They are counting the original date of exploitation as the start date for notification. I would think a more responsible and fri…

OTOH, it's highly likely that other people already found this. So by disclosing now, they are still helping users by making sure they don't think this bug was fixed.

But they shouldn't try to justify it based on the timelines. Especially if they noticed a bug in the original patch, but held off on saying anything.

At the same time.... It's business. They didn't act maliciously (exploiting or selling the exploit to bad actors). If the way to build a career is to rack up CVEs, well then that's what people will do, right?

Re: Android libstagefright still exploitable

#25

Post by andrewguenther »

johansch wrote: post #13

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

Right...

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-12...

Re: Android libstagefright still exploitable

#26

Post by ocdtrekkie »

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?

Because withholding security updates over accepting horrifically invasive UI and branding changes is unacceptable.

Similar to Microsoft still patching Vista nearly ten years later, Google should be obligated to deliver security patches to all versions of Android within a reasonable timeframe.

Re: Android libstagefright still exploitable

#27

Post by captainmuon »

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 could add that to the language in a backwards-compatible way? Maybe add a new builtin (compiler-specific, but shared by popular implementations?) like

    if __no_overflow(x + y > z)
that would make the addition of two ints become long, two shorts become int32, and so on. (Two long longs would internally become BigNums, but that wouldn't be exposed.)

And while we're at it, add a __checked(a+b) construct, that sets a flag if overflow occurs (or maybe raises an assertion - or maybe we should have both options).

Re: Android libstagefright still exploitable

#28

Post by pacquiao882 »

The bigger issue of libstagefright is that it there's a ton of code involved with media playback at the native level that has access to many system resources. This specific exploit was just looking at a small part of the MP4 handling -- one of the many parts within the library. It is very likely more severe exploits like this one will surface as a result of this huge library.

Re: Android libstagefright still exploitable

#29

Post by matthewmacleod »

johansch wrote: post #13

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

That's a bit silly though, isn't it? The iPhone has had quite a few major RCEs over the years.

Re: Android libstagefright still exploitable

#30

Post by wutbrodo »

anon1385 wrote: 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.

Post reply on HN