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.
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.
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.
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.
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.
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.
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.
On an ethical level: Because there's quite a lot of difference between major versions, and you shouldn't be forced to replace one product with another to get basic fitness-for-purpose fixes on something that's only a year or two old.
On a practical level: Tons of devices are stuck on 4 and it's not hard to backport the fix. Once you do that, just compile it for the devices you sell already.
Because I shouldn't be required to accept giant releases (including broken functionality I rely on) to get security updates. Because it noticeably worsens battery life. Because it's a horrid practice to screw with software on production gear just for shits and giggles, and what is your phone if not a production device?
If Microsoft came out and said they weren't fixing a critical Windows 7 security flaw to force people to upgrade to Windows 10, HN would have bottomless wells of criticism. Google refuse to issue a security fix for a critical vulnerability for a less-than-2-year-old OS, and what, that's ok?
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.
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.
Google released a patch for Stagefright for 4.4.x anyways. So this is not the reason. The problem is that Android is currently flawed in implementation in that it treats security fixes and system upgrades the same way. There's only one "path" to get updates. So by blocking 5.1, I also don't get a Stagefright fix for my 4.4, even though a fix for 4.4 already exists.
Also, companies like Microsoft do charge extra for supporting old versions. Specifically, versions OVER TEN YEARS OLD. (Vista security updates are still free!) However, Google does not properly support OS versions released within the last year, which is drastically worse.
Microsoft is a very unusual case, in that they have a brand that is built on legacy support and enterprise stability.
Very few other companies in this industry are willing to put up with the pain of maintaining multiple versions, especially without paying enterprise users who care.
But Google has been heavily pushing their new "Android for Work" concept. Microsoft's support lifecycle is expected by enterprises today. Why on earth should people trust Google with their business data if they won't provide enterprise-level support?
The problem with general updates is that they tend to screw up your workflow, settings, etc. in different ways (they call that "features"). Personally, I'm also more and more reluctant about installing updates for most apps and systems.
Ideally, security updates would be distinct from general system or application updates. Don't Apple and Microsoft do that for their OSs?
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.