10 ms·

Android libstagefright still exploitable

• josh2600 11y ago
  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.
  • deleted 11y ago
    [deleted]
  • jimrandomh 11y ago
    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.
    • josh2600 11y ago
      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, but, if someone found a bug in the heartbleed patch today and disclosed it immediately with the original patch date as justification, I would imagine many would be screaming bloody murder.
      • adrianlmm 11y ago
        What? If your intention is to apoligize Google, can you do it in a more clear way?
        • josh2600 11y ago
          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.
          • adrianlmm 11y ago
            And I don't believe you.
          • ascendantlogic 11y ago
            As stated elsewhere, the original bug was reported in April and not publicly disclosed until July. The issue here is that the patch did not sufficiently remove the flaw. This gets to the crux of the debate on what is "responsible" disclosure. One would assume that the patch would be studied by legitimately malicious attackers and presumably they would independently realize the flaw still existed and continue abusing it. By stating that the flaw is still present the public at large can make educated decisions about their handling of MMS messages instead of assuming everything is fixed when in fact it is not. The flip side is now that less capable malicious attackers will also be made aware. And so the endless argument continues.
      • roblabla 11y ago
        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.
      • tossera 11y ago
        The bug is not new after the patch. The patch just failed to fix the original bug.
      • smtddr 11y ago
        This is a grey area. Not everyone is going to agree. For example, if some email client can cause arbitrary command execution by adding a malformed email as CC, like nobody@file:///calc.exe or something, vendor patches it, then the workaround to use the exploit again is nobody@file\:\ / \ / \ /calc.exe , I don't consider that a new bug and doesn't deserve the same grace period for disclosure, IMHO. Now, if it turned out that the email client's ability to show embedded images in the message-body and setting the metadata in a PNG to "file:///calc.exe" caused the calc program to run... I think that IS a new bug and does deserve another grace period because its "point of entry", rendering a PNG and processing its metadata, is very different from parsing the email to/from/cc/bcc fields.
  • x0x0 11y ago
    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.
    • ocdtrekkie 11y ago
      Same problem. My options for my Droid Turbo are suffer Android 5.x or get a Windows Phone. ...I'm getting a Windows Phone.
      • bitmapbrother 11y ago
        Because Microsoft is right on top of those Windows Phone updates, right? There are Windows Phones on U.S carriers still sporting Amber.
    • matthewmacleod 11y ago
      I shouldn't be required to do to get security releases. Why should you not be required to do that?
      • ocdtrekkie 11y ago
        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.
        • oconnor663 11y ago
          I think it's more difficult to patch old versions of Android than you're suggesting. You can't just backport a few lines of code and hope for the best. You have to maintain all the testing infrastructure that you had in place back when that version was supported, to avoid introducing new bugs with your change. And if you're releasing a security fix, you now have to coordinate that release across all versions that were vulnerable, because patching the vulnerability in one version usually discloses it in all versions. So you've slowed down fixes for your most up-to-date version, on top of the added expense of all that testing. Companies like Microsoft make boatloads of money in exchange for supporting old versions of their software like that. But nobody is going to pay Google enough to support old Android phones.
• archmikhail 11y ago
  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-nearly-a-billion-android-users-under-the-bus-refuses-to-patch-os-vulnerability http://www.extremetech.com/mobile/197346-google-throws-nearl...
  • kreutzwj 11y ago
    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.
    • canistr 11y ago
      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/Mobility/android-s-stagefright-vulnerability 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
      • kreutzwj 11y ago
• anon1385 11y ago
  >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.com/item?id=8896221 https://news.ycombinator.com/item?id=8896221
  • deleted 11y ago
    [deleted]
  • kyrra 11y ago
    They have become a bit more flexible[0] after the Windows issue. They are still living by the 90 day policy, but baked in some flexibility if the vendor is communicating with them. [0] http://googleprojectzero.blogspot.com/2015/02/feedback-and-data-driven-updates-to.html http://googleprojectzero.blogspot.com/2015/02/feedback-and-d...
  • wutbrodo 11y ago
    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.
    • anon1385 11y ago
      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).
• VMG 11y ago
  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?
  • CUViper 11y ago
    Rust debated this for a while, and eventually did decide to make overflows panic -- but they are checked only in debug builds. https://github.com/rust-lang/rfcs/blob/master/text/0560-integer-overflow.md https://github.com/rust-lang/rfcs/blob/master/text/0560-inte...
  • ploxiln 11y ago
    Performance. That's an extra branch on every arithmetic operation.
    • barrkel 11y ago
      That's not how you'd implement it if you had a choice though. You'd rely on a certain page of memory not being mapped on the target platform (the page that starts at address 0 is often a fine choice) and you'd issue a conditional move that touches that address. You'd rely on the CPU exception interrupt mechanism to branch. I know modern ARM instruction sets don't have conditional instructions like that, but they may have something similar for extremely infrequently triggered control flow. The same kind of trick can be handy in a variety of programming language and GC implementation techniques.
    • zurn 11y ago
      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 https://news.ycombinator.com/item?id=7847980
      • johncolanduoni 11y ago
• jimrandomh 11y ago
  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 are still vulnerable. You can partially mitigate the risk by disabling auto-downloading of MMS messages in whichever app you have set to handle text messages, such as Messaging or Hangouts. If you have not done so already, this is urgent. Furthermore, you should assume that auto-downloading of MMS messages will not ever be safe, no matter how many individual security fixes are applied, until this component of Android is significantly re-architected.
  • pacquiao882 11y ago
    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.
  • ajross 11y ago
    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?
    • semenko 11y ago
      The isolation seems mostly defined by this SELinux policy: https://github.com/android/platform_system_core/blob/lollipop-mr1-release/rootdir/init.rc#L564 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 Android kernels are also terribly outdated...
• hoopism 11y ago
  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 friendly date would be August 7th. Just me.
  • anon1385 11y ago
    I sympathise with your point, but one complicating factor is that when big security vulnerabilities like Stagefright are found a lot of people then turn their attention to that code. Either finding other issues in the same code, or that the patch isn't fully effective. It was similar with Shellshock, where there was a series of patches as more issues were found because suddenly people were looking at this bit of code that had previously been uninteresting. I'm not sure keeping it secret for long serves much purpose in this kind of situation; the eye of Sauron is already gazing on the code in question. I doubt these people were the only ones to notice that the patch didn't completely fix the problem.
    • hoopism 11y ago
      That's fair. Perhaps I am more alarmed by the assertion of the author that they had given 100+ days notice... it came off like they talking about the patch and not the original issue.
  • MichaelGG 11y ago
    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?
  • 11y ago
• gionn 11y ago
  So, a security engineer, working at Google, cannot catch that a 4 lines patch is ineffective?
• johansch 11y ago
  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).
  • andrewguenther 11y ago
    Right... https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1266 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-12...
  • matthewmacleod 11y ago
    That's a bit silly though, isn't it? The iPhone has had quite a few major RCEs over the years.
  • autobahn 11y ago
    because somehow magically an iphone is more secure because reasons? I agree that iphone's patching model is superior to android, but your statement shows a bit of ignorance.
    • johansch 11y ago
      Because they have a working patching model, yes.
      • bitmapbrother 11y ago
        What about the other 15% that don't receive patches of any kind? Should they remain vulnerable just because their devices are too old? I guess that "working patching model" has a time limit.
  • redwards510 11y ago
    How do you think jailbreaking is accomplished?
• lnanek2 11y ago
  Doesn't seem very responsible behavior by the reporter. Google accepted the suggested patches, fixed the original cases. Now some other cases are discovered for these larger numbers, OK, that seems like a new thing to fix next. Not sure why I have to read paragraphs of hate when the company put the suggested patches in already. Seems like just an excuse so they can ride the page view wave.
  • Dylan16807 11y ago
    This doesn't seem hateful to me, and the problem is that google took so long to fix anything at all on top of barely caring about the fix. Why not fuzz the fixed version for 10 seconds?
• jsingleton 11y ago
  There was an Android update pushed to my phone recently. I wanted to know if it was an urgent security fix so I checked the diffs. It's hard to tell but it doesn't seem to be. It's a bunch of fixes to do with video out, SIP etc. I thought maybe the patch fixed this security flaw. It wasn't clear what it was for from the phone. I had to do a fair bit of digging. Are there any change-logs or release notes for these system updates?
• captainmuon 11y ago
  And I was wondering at the beginning of the article why they were doing if (SIZE_MAX - chunk_size <= 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).
  • CUViper 11y ago
    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.html https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins...
    • captainmuon 11y ago
      Well, it wouldn't reach into functions. It would mainly just change the + and - operators within its scope to return a larger type. So instead of int32_t plus(int32_t left, int32_t right); the plus operator would be equivalent to int64_t plus(int32_t left, int32_t right); So basically int32_t a = 2000000000; int32_t b = 2000000000; int64_t c = __no_overflow(a+b); // now c is 4000000000; I don't claim the idea to be flawless or completely thought out, but I believe something like that could be one of the more useful C language extensions. Oh, and thanks for the link!
  • deleted 11y ago
    [deleted]
• pacquiao882 11y ago
  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.
  • mike_hearn 11y ago
    It's a bit surprising because so much of Android is written in Java. Given hardware decoding of the video itself I wonder why Stagefright needs to be written in C++ at all. Media processing code has been notorious for being exploit ridden for years, so it's not like this problem was unpredictable.
• ikeboy 11y ago
  Can carriers (and by extension, the Hangouts backend itself) check messages and block "evil" ones? Wouldn't that be an easier way of fixing these things quickly? At the very least, Google should block any Hangouts message that triggers the bug even on non-updated devices.
• autobahn 11y ago
  Just to give everyone a bit of calm, nobody's demonstrated a successful exploit with ASLR bypass. Meaning that while the vulnerable is technically exploitable, the chance of system compromise is very low on modern android phones (I think post 4.0)
  • kyrra 11y ago
    Per the wikipedia article[0] ASLR (address space layout randomization) was first added in 4.0 and fully enabled across the OS in 4.1. To go with that, 91% of android phones are on >= 4.1, and 95% are on >= 4.0 [1]. [0] https://en.wikipedia.org/wiki/Stagefright_(bug) https://en.wikipedia.org/wiki/Stagefright_(bug) [1] https://developer.android.com/about/dashboards/index.html https://developer.android.com/about/dashboards/index.html
• stevenh 11y ago
  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 minutes of being released in the wild? 1. Text payload to victim 2. Payload executes on victim's phone and texts itself to all of the victim's contacts 3. Repeat Assuming the average Android phone owner has 20 contacts who also have Android phones, and assuming also that texting the payload to those 20 people would take two minutes to complete, the infection would spread exponentially and only take ten minutes for the initial text to result in the infection of 10 billion devices worldwide. Why am I not currently being bombarded with MMS video texts from infected devices? It frankly seems a bit miraculous. Did Google set up an emergency arrangement with all of the carriers to block suspicious video texts so this wouldn't happen?
  • danielweber 11y ago
    1. Maybe it's not as easy as you think. 2. The MMS system isn't as anonymous as the Internet and someone didn't want to burn an identity making this worm. 3. A combination of 1 and 2, where the people with technical skill to do this would only use it on specific targets.
  • guelo 11y ago
    Because, despite the hype, the bug doesn't give full root access to the phone.
  • mike_hearn 11y ago
    Apparently the exploit doesn't work on devices that have good ASLR (based on a /. comment by someone who works on the Android security team).
  • m3rc 11y ago
    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
• ambrop7 11y ago
  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) .
• RexRollman 11y ago
  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.
  • chimeracoder 11y ago
    > 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 obscurity is not entirely without value, but it's not particularly strong as a defense either.
    • RexRollman 11y ago
      I think it is worst. As least with XP, you didn't have Dell preventing you from getting a security update.
• cautious_int 11y ago
  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 integer if the types don't match in a arithmetic operation, or an assignment.
  • Dylan16807 11y ago
    I can understand the comparison passing, but why in the world does nothing warn about the truncation inside the new operator?
    • cautious_int 11y ago
      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.
      • Dylan16807 11y ago
        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.
        • cautious_int 11y ago
          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.
• mondoshawan 11y ago
  http://www.cyanogenmod.org/blog/more-stagefright http://www.cyanogenmod.org/blog/more-stagefright Looks like Cyanogenmod has patched this toot-sweet.