Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Android Google Security

Google Rebuilt the Android Media Stack To Prevent Another Stagefright 50

Posted by msmash 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.
This discussion has been archived. No new comments can be posted.

Google Rebuilt the Android Media Stack To Prevent Another Stagefright More

Google Rebuilt the Android Media Stack To Prevent Another Stagefright

Comments Filter:

  • Just do it in rust (Score:1)

    by Anonymous Coward

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

    • Re: (Score:2)

      by mccrew ( 62494 )
      It's not either/or. You build security in layers.
    • 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?

  • So, are they lying or stupid? (Score:3)

    by bistromath007 ( 1253428 ) on Wednesday September 07, 2016 @11:34AM (#52841221)
    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?

    • 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 ar

      • Re: (Score:2)

        by mccrew ( 62494 )

        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.

        • 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 y

          • Re: (Score:2)

            by mccrew ( 62494 )

            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.

            • 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

      • Re: (Score:2)

        by tlhIngan ( 30335 )

        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

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

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

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

    Apple is next.

  • 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?

  • 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 :-)

Slashdot Top Deals

If you do something right once, someone will ask you to do it again.

Close