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.

29 of 50 comments (clear)

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

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

      Such as which driver exactly?

    5. 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.
    6. 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?
    7. 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.
    8. 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.
    9. 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).

    10. 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
    11. 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
    12. 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?

    13. 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.
    14. 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. 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.
  4. Re:Read as: Google fails to patch Stagefright by LichtSpektren · · Score: 1

    Forking OpenSSL comes to mind

  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. 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.
  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 tepples · · Score: 1

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

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

  10. 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 :-)

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