Google Patches More Stagefright Vulnerabilities In Android (threatpost.com)
msm1267 writes: The Stagefright vulnerabilities are the gifts that keep on giving. Months after the potentially devastating security flaws in the mobile OS were publicly disclosed, Google continues to send out patches addressing vulnerabilities related to the initial reports. Today's monthly Android security bulletin includes a fix for another flaw in the Stagefright media playback engine, one in libutils where the Stagefright 2.0 vulnerabilities were found, and two in Android Mediaserver where all the vulnerable code runs. The over-the-air update was released today to Google's Nexus devices and will be added to the Android Open Source Project (AOSP) repository in the next two days; Google partners including Samsung were provided the patches on Oct. 5, Google said, adding that the vulnerabilities are patched in Build LMY48X or later, or in Android Marshmallow with a patch level of Nov. 1.
And how many months if EVER will Verizon and carriers send out these updates? I'm still waiting for the last 3 patches that they haven't done shit about.
I have a 2.5 year old phone that I otherwise love and while it's EOL, I still use it extensively.
The idea that a phone can be not even 3 years old and not have any hope of getting updates is something I balk STRONGLY at.
I have no problem with your religion until you decide it's reason to deprive others of the truth.
Not sure you are following the analogy, because the original complaint is that you need the carriers permission to install an update from Google.
Meanwhile Apple is supporting devices around four years old with updates, no matter what carrier you have.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
I might have purchased a copy of that book if there was actually an e-book version of it.
Anyhow, it's important to point out that security bugs aren't exactly like typical bugs. You can't test for security using unit tests... it's something that needs to happen in an audit. You need to be actively searching for ways to break code, and you need to know the techniques with which this is usually done. Most programmers are not trained how to do this. Do you think anyone actually tried to fuzz-test this library? I wonder.
Allowing a multimedia library to play downloaded, untrusted content as elevated privileges is a pretty obvious problem in hindsight. We've seen flaws in many other internet-facing multimedia rendering or playback libraries before. libstagefright is now going to undergo some intense scrutiny by both hackers and security firms alike - I'd be surprised if this is the last we hear of this.
Irony: Agile development has too much intertia to be abandoned now.
In all the conversation so far no one bothered to post anything about how to actually verify if the vulnerability exists on a system or whether anyone is offering a vulnerability scanner for this.
The best scanner I've seen so far for previous versions of Stagefright vulnerabilities is this one.
Google should admit there is a problem in Android's model of getting updates and do something about it.
It is not just code.
If they don't care because Android is doing well in terms of market share etc, they should read comments & stories about Nokia Symbian. Developers, users, authors were telling them everything which were wrong and they were laughing at them showing their massive marketshare. Now, their own Google Keyboard didn't autocomplete Symbian, it is that irrelevant.
Given that the (deliberately configured, 'as designed') behavior for stagefright was to silently restart every 5 seconds if it crashed, I can only assume that there was some internal pessimism about the robustness of the library.
I don't doubt that dealing with all the various ghastly corner cases in codecs and container formats was deeply unpleasant; but it is worrisome that priority was apparently given to avoiding the appearance of failure, rather than really clamping down on what such a dangerously unpredictable part of the system was allowed to do; and when it could silently retry, rather than rejecting input.