Slashdot Mirror

← Back to Stories (view on slashdot.org)

Google Rebuilt the Android Media Stack To Prevent Another Stagefright

Posted by msmash on from the security-woes dept.

Reader Trailrunner7 writes: Android Nougat is bringing with it a slew of security improvements, many of them under the covers, and the one that likely will have the biggest long-term effect is the major rebuilding effort Google undertook on the media stack. That component of the operating system is meant to process audio and video, and it's been a weak spot in Android. The media stack includes the mediaserver process, which is used by a number of apps on Android devices. Researcher Josh Drake last year discovered a critical vulnerability in the libstagefright function in the media stack, which could allow an attacker to get complete control of a target device by sending a malicious MMS message. The Stagefright vulnerability is among the more widespread and dangerous flaws to affect Android, and though Google patched it last year, the company decided to take a more systemic approach to the problem in Nougat. Rather than addressing vulnerabilities on a case by case basis, Google implemented technologies to prevent a large group of bugs.

50 comments

  1. Just do it in rust by Anonymous Coward · · Score: 1

    no need for this sandboxing stuff. Sandboxes should be a second line of defense, not a first one.

    1. Re:Just do it in rust by mccrew · · Score: 1

      It's not either/or. You build security in layers.

      --
      Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
    2. Re: Just do it in rust by fubarrr · · Score: 1

      Google hires lamers. Lamers dunno how to compile insecure libs with aslr, moreover running them in a root process Moreover, wtf are they using very uncommon media decoder libs that apparently werent even automatically checked for overfows? Do wish to avoid using GPLed code so hard that they are ready to push that crap into production firmware?

  2. So, are they lying or stupid? by bistromath007 · · Score: 2

    By my understanding, devices they aren't putting Nougat on, like the Nexus 5, are still supposed to get security updates. This seems to be a major security update. So, rather than just put Nougat on the Nexus 5, which they easily could with its hardware, they've committed to individually patching a category of bug that they just put a bunch of work into not having to individually patch. Or is my phone continuing to get security updates a lie?

    1. Re:So, are they lying or stupid? by Anonymous Coward · · Score: 0

      I think the issue with Nexus 5 is that the hardware didn't have compatible drivers for Nougat to work correctly. That's true for a lot of other phones on the market as well, so it's not as though it's a duplication of effort for no reason.

    2. Re:So, are they lying or stupid? by bluefoxlucid · · Score: 2

      This is an architectural change, not a patch for a security vulnerability. It doesn't remove a vulnerability; it changes the nature of a type of theoretical vulnerabilities.

      Your argument is akin to claiming a company's new product has major new safety features, and thus that they are compelled to perform a safety recall on unsafe defects in prior products which don't have said features. Suddenly all cars made before a certain year must be recalled because they don't have airbags or antilock brakes and are thus defective.

      --
      Support my political activism on Patreon.
    3. Re:So, are they lying or stupid? by EndlessNameless · · Score: 1

      They see it as a general security improvement and cost avoidance. They won't have to deal with individual vulnerabilities in the future, so they will avoid expenses over time.

      Since Android 5 and 6 will remain in the wild for years, they will be fixing those issues anyway---Lollipop and Marshmallow run on more than just the Nexus 5.

      --

      ---
      According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
    4. Re:So, are they lying or stupid? by Anonymous Coward · · Score: 0

      They will still have to deal with them, but hopefully not as 0 day vulnerabilities, but just bugs or crashes.

    5. Re:So, are they lying or stupid? by LichtSpektren · · Score: 1

      "which they easily could with its hardware"

      I've heard this assertion before but I see no proof for it. It's possible Google just wanted to obsolete the Nexus 5 faster, but nobody seems to have any sources to back this up.

    6. Re:So, are they lying or stupid? by Anonymous Coward · · Score: 0

      We're all doing it wrong.

      When I buy a bunch of hardware components from newegg and assemble a new desktop, it doesn't even occur to me that I'm going to be asking the manufacturers (or newegg) for software. (Video chipsets are the one exception, and it's a very uncomfortable one where I know I'm doing it wrong, and therefore have a ton of pressure on me to try to get something that has free drivers instead. Nvidia still sells me stuff in spite of me knowing the dangers, and each time it happens, they can't take it for granted.)

      We should stop treating handheld PCs as a special case. You supply the hardware, I load the software, and I apply updates. And I know that I'm going to be able to supply updates for long-ass time. 10 years isn't even slightly unreasonable.

      Pretty much the only thing standing in the way, is that they've all gone to a lot of extra trouble to make it hard for me to supply the software. That needs to change.

    7. Re:So, are they lying or stupid? by danbob999 · · Score: 1

      Such as which driver exactly?

    8. Re:So, are they lying or stupid? by wbr1 · · Score: 1

      No drivers is often the case for 3rd party ROMS. Should not be for google. They commissioned that device be built and were there for the design work. They wrote the drivers (or were heavily involved) for every chip, sensor and camera in that phone. Saying they cannot now write or commission a driver for nougat is untrue. It may not be economically feasible (I will leave ethical feasibility for another debate), but it is well within their ability to do so.

      --
      Silence is a state of mime.
    9. Re:So, are they lying or stupid? by Anonymous Coward · · Score: 0

      http://www.androidcentral.com/Android-7-snapdragon-800

      Since it is apparently related to the snapdragon 800, which does a number of things, I'm not sure. Quite possibly the graphics aspect of it.

      Someone else said that google wrote the drivers since they were a manufacturer of the device. Last I checked LG made the nexus 5 and android still uses binary drivers. so Meh. Seems perfectly plausible to me.

      But go ahead, Raise the pitchforks =) I mean if you do manage to get google to change their course and apply Nougat to my nexus 5 I sure ain't gonna complain.

    10. Re:So, are they lying or stupid? by Anonymous Coward · · Score: 0

      > Lollipop and Marshmallow run on more than just the Nexus 5.

      And how long do you think LG and the others will continue to do updates?
      There is no incentive for them and Google knows it.
      It's a great mechanism for Google.
      They make a fortune today and never get blamed later when the security holes hit the fan.
      Google assumes no responsibility and could care less!
      Do you have a Kit-Kat time bomb in your pocket?
      Time to update to Nougat.
      My ass.

    11. Re:So, are they lying or stupid? by Dishevel · · Score: 1

      If you care, you could buy your phone and not lease it. Then make sure you buy one that allows you to "own" it. You can change the ROM anytime you want. Apply patches and customize however you want. Google allows this. Or you can get a shiny S7 Edge or a iPhone 7 and bitch about "The Man" keeping you down.

      --
      Why is it so hard to only have politicians for a few years, then have them go away?
    12. Re:So, are they lying or stupid? by mccrew · · Score: 1

      This is an architectural change, not a patch for a security vulnerability. It doesn't remove a vulnerability; it changes the nature of a type of theoretical vulnerabilities.

      Yep. Trading in one set of problems for a different set of problems.

      --
      Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
    13. Re:So, are they lying or stupid? by bluefoxlucid · · Score: 1

      If the risks in the new set of problems are more-manageable, that's a good strategy. Address space randomization reduces the size of contiguous unallocated memory regions at application load time; applications rarely try to allocate one gigantic contiguous block the size of a significant fraction of the address space, so it's harmless except in 32-bit systems where Linus's e-mail client mmap()s a 2.6GB file directly into what is, in the best case, a 2.8GB VMA region (all of VMA is about a 3GB spread, and you're mapping down from the bottom of the stack), which is going to fail when Linus gets a few thousand more e-mails. New problem, yes; less of a problem than easy code injection.

      --
      Support my political activism on Patreon.
    14. Re:So, are they lying or stupid? by tlhIngan · · Score: 1

      This is an architectural change, not a patch for a security vulnerability. It doesn't remove a vulnerability; it changes the nature of a type of theoretical vulnerabilities.

      Now the question becomes - they got rid of stagefright bugs by removing stagefright. But did introducing a new media stack introduce a whole pile of new security bugs? This is important because starting from scratch generally does end up with a pile of bugs (see Apple's attempts at an init system, or even their SMB implementation).

      So yes, no more stagefright bugs. But now a whole pile of new bugs because it's new code. And parsing media files isn't necessarily easy (which is why we had those bugs in the first place).

    15. Re:So, are they lying or stupid? by Anonymous Coward · · Score: 0

      But your car analogy isn't at all the same as this. Cars usually need a *physical* recall to retrofit security items to them. Also, there is a limit to *physical* changes that can be made to a car once it is manufactured. This is entirely different than *software* changes. Google is just being a fucking cheap-ass. It would cost them a pittance (if anything) to update Nexus 5 but they can't be bothered. People that bought a Nexus 5 can be screwed over because they already bought the phone - they're not going to be returning it. I would expect a $300-600 cellphone to last more than 3-4 years without becoming a security nightmare.

    16. Re:So, are they lying or stupid? by amRadioHed · · Score: 1

      TL;DR: The theory is that Google couldn't update their Nexus 5 to Android 7 because the hardware doesn't meet an arbitrary requirement for Vulkan support that Google set.

      --
      We hope your rules and wisdom choke you / Now we are one in everlasting peace
    17. Re:So, are they lying or stupid? by amRadioHed · · Score: 1

      I think a big part of the problem is that phones don't have standardized hardware interfaces the way PCs do. You can't just install Linux on a computer with completely proprietary hardware.

      --
      We hope your rules and wisdom choke you / Now we are one in everlasting peace
    18. Re:So, are they lying or stupid? by viperidaenz · · Score: 1

      Google said they would update the phone with new Android version for 2 years from the release date.
      They did. It was released in October 2013. It now has Marshmellow, released in October 2015.
      How has anyone been screwed?

    19. Re:So, are they lying or stupid? by mccrew · · Score: 1

      If the risks in the new set of problems are more-manageable, that's a good strategy. .

      Yep, agree with what you said. But you don't know whether new problems are more manageable until much later. Only point I am trying to make is that re-architecting out old problems is great, but with any non-trivial project you introduce new (improved! :^) cracks for things to fall through. Kind of like how the military is always preparing new methods to win the last war.

      --
      Hey, Windows users, there is no such thing as "forward" slash, there is only slash and backslash.
    20. Re:So, are they lying or stupid? by Anonymous Coward · · Score: 0

      Nice! Way to straw man it!

      The FUD is strong in this one...

    21. Re:So, are they lying or stupid? by bluefoxlucid · · Score: 1

      That's called risk. Risk is manageable by historical information. For example: we have modern programming practices and design patterns, which we know reduces the likelihood of bugs in the first place, and improves maintainability of large and complex code bases. A legacy code base using old design and being updated to fit new technology (new codecs, transports, hardware, APIs, and so forth) will insert small amounts of code into a large basis of high-risk-architecture code, causing risk; a refactor or rewrite into a new architecture will use all lessons learned about the specific threats in this type of software, as well as all lessons learned about the new type of architecture, making bugs less-frequent, less-severe, and easier to fix.

      It's easy to determine that such a rewrite is 60%, 80%, 95% likely to be better, or so forth, given enough data about the solution. Risk management is part of writing software, and techniques which allow safe error conditions reduce those risks even when programmer error is to blame. If your software fails to validate user input properly and leads to a condition in which an exception is thrown, it doesn't go any further, and thus doesn't encounter code which could respond by opening up larger bugs and possible security risks, thus reducing the surface affected and thus the likelihood of a security vulnerability.

      By the same token, there is a small frequency of not being better, or being worse. That's muddy, too: if you generate 11 vulnerabilities instead of 86, those 11 could be novel--you actually saved yourself from 85 vulnerabilities, had 1 that would have occurred either way, and had 10 more that happened because your new rewrite was imperfect. By the numbers, it's better in total. A separate risk in simply writing software that's ultimately crap exists, and is much less likely.

      --
      Support my political activism on Patreon.
  3. Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

    Rebuilds OS instead.

    1. Re:Read as: Google fails to patch Stagefright by EndlessNameless · · Score: 4, Interesting

      Rearchitecting a product so that it is inherently less vulnerable is exactly what every software developer should be doing.

      Taking a stab at Google over this is something only an idiot would do.

      --

      ---
      According to the latest ruleset, this post should be modded as Vorpal Flamebait +5.
    2. Re:Read as: Google fails to patch Stagefright by LichtSpektren · · Score: 1

      Forking OpenSSL comes to mind

    3. Re: Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

      Article says they already patched it

    4. Re:Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

      Does that mean 92.4% of all Android users are idiots too?

    5. Re: Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

      IPhone users would probably agree with that statement

    6. Re:Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

      Rearchitecting a product so that it is inherently less vulnerable is exactly what every software developer should be doing.

      Taking a stab at Google over this is something only an idiot would do.

      Google has encouraged the development of an ecosystem where doing "what every software developer should be doing" means that the vast majority of users will will not benefit.

      Granted, pointing out this fact does not indicate a better alternative at this time. Google should re-architect and work on redundant patches for the many users who will not benefit from that effort because their device will not receive an upgrade.

      It would be nice if Google would generally get its Android shit together though, because it is easy to see how their current position is unsustainable and will almost certainly lead to shorter support periods for devices (and thus even more churn and chaos in the Android market).

    7. Re:Read as: Google fails to patch Stagefright by Hydrian · · Score: 1

      It was. Take a look at http://www.libressl.org/.

      --
      No good deed goes unpunished.
    8. Re:Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

      I just don't see it getting much more secure by rearchitecting by developers who are so incompetent that they don't spot an integer overflow even after being pointed at the single buggy line.
      Unless they actually had some competent people put on this, it seems a recipe for making it even worse or at least not much better, while potentially wasting a ton CPU power.
      And without actually fixing the broken code it's kind of like putting lipstick on a pig either way, sure an improvement but it's still crappy, buggy code.

    9. Re:Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

      Re-architecturing a project is kinda like the story of the three little pigs.

      Google builds a house made out of straw and assures the little pig (consumer) that it is perfectly safe to live in. Predictably, it falls apart when the big bad wolf (hackers) sneeze in its general direction, and the little pig gets devoured. So now Google announces that *this time* they'll make a much better house: one made out of brick.

      This is inexcusable. It is just bad engineering. Instead of following best practices (build brick houses), they built a crappy one and hoped that nobody would notice. And now they OBVIOUSLY need to redesign their house.

      Note that I am not saying that you should never re-engineer. One day, brick houses will become obsolete, and we'll have to start building houses out of Titanium. But this isn't what happened here. Media playback hasn't fundamentally changed since stagefright was first made, and other vendors (Microsoft, Apple, Linux distros, BSDs, Mozilla, others) haven't had such a catastrophic failure that required a complete redesign of the media stack. Only Google. Because they are incompetent.

    10. Re:Read as: Google fails to patch Stagefright by LichtSpektren · · Score: 1

      I'm not sure what the point of your response is. Obviously I'm aware it was forked, that's why I said it comes to mind when thinking about libraries/functions that have a rotten base.

    11. Re:Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

      I just don't see it getting much more secure by rearchitecting by developers who are so incompetent that they don't spot an integer overflow even after being pointed at the single buggy line.

      You're funny thinking that integer overflows are only caused by bugs. Let's have a think about the context here: media server is dealing with audio, images and video. Most media formats are self-describing, that is they contain metadata about the nature of the media. e.g.: an image file typically contains Height, Width and Depth metadata. Someone crafting dodgy images can specify Height, Width and Depth values that are guaranteed to cause an integer overflow condition at run time - in this example, as the media server is calculating how much memory it needs to allocate to decode a bitplane. This isn't a bug in the media server software, per se.

    12. Re: Read as: Google fails to patch Stagefright by Anonymous Coward · · Score: 0

      Of course they would. The group think is strong among the apple base.

  4. Google hasn't done a damn thing by Anonymous Coward · · Score: 0

    The Stagefright vulnerability is on millions of phones that will never be updated.
    Connect one of these beasties to your network and you could be SOL.
    The phone manufacturers don't do updates.
    They don't even offer updates.
    Google understands how serious the problem is, but they are too busy making money, hand over fist, to worry about it.
    Sure they make a change to the Android Nougat media stack, but in time, its unpatched vulnerabilities will bite users in the butt.
    Google won't risk offending the manufacturers.
    So buy an Android phone - and a prayer book to go with it.

    that are

  5. It starts... by poofmeisterp · · Score: 1

    The "hidden fixes whenever we want, oh and full control of your device for your safety and ours" maneuver starts now.

    Apple is next.

  6. so by Anonymous Coward · · Score: 0

    Don't worry,they left plenty of other great gaping holes in android etc so that people can drive trucks through androids so called security...
    One day Google might actually do something about the awful radio stacks they keep foisting on the public,idiot reviewers etc go on about screens sucking battery to death,try looking at how bad the radio stack is compared to others,that's where loads of battery is going

    1. Re:so by viperidaenz · · Score: 1

      Google don't write the code that controls the radio, the vendor who makes the radio chip does.
      Blame Qualcomm and others for that.

  7. Is Vulnerability a bug? by sdinfoserv · · Score: 1

    The author’s last sentence insinuates that vulnerabilities are bugs If code is designed to accomplish specific tasks using specific input, is it a bug when someone nefariously alters input to derive unintended results?

    Thoughts?

    1. Re:Is Vulnerability a bug? by viperidaenz · · Score: 1

      A bug is a flaw in the code that produces incorrect or unexpected results.

  8. LibreSSL fails to eat its own dog food by tepples · · Score: 1

    The real WTF is that https://www.libressl.org/ produces "Firefox can’t establish a connection to the server at www.libressl.org." They aren't even eating their own dog food.

    1. Re:LibreSSL fails to eat its own dog food by Anonymous Coward · · Score: 0

      I don't think any browser can connect to port 443 because it looks like there is nothing serving on that port.

      [~]nc -vz www.libressl.org 443
      nc: connect to www.libressl.org port 443 (tcp) failed: Connection refused
      [~]

    2. Re:LibreSSL fails to eat its own dog food by tepples · · Score: 1

      That was my point. Why isn't the website of a TLS implementation available through TLS?

  9. Relying on binary blobs by vovin · · Score: 1

    The whole media stack is still based around the binary blobs provided by the SoC supplier and wrapped by hacking shims to provide an common API.

    It would be nice to see Google use it's power for good and start forcing manufacturers to open up the SoCs. Unlikely, but I can dream :-)

  10. MediaPlayer Buffer Size by Anonymous Coward · · Score: 0

    Has the hardcoded preload buffer size been fixed yet? It makes anything using MediaPlayer completely unusable on low-bandwidth connections of less than a few megabits.

    Hold on, let me anticipate every reply: "Get more bandwidth you fucking loser! It's 2016 already! Lolololololol u fucking suk why the shit you using android u kno android is for young people on fast fast fast internets not old shit lik u."

  11. Let's face it by Anonymous Coward · · Score: 0

    Google can write bugs and move them around as well as Microsoft or Adobe. This is an announcement of "moving bugs around". Don'g get excited.