Google releases a fix for flash, before Adobe
securitywatch.pcmag.com
securitywatch.pcmag.com
What if they have detected black hats exploiting the vulnerability. Should they sit on a fix?
What if they were building their own implementation of a programming language or tool. For example, what if they found a bug in JS that could be used to exploit browsers. Arethey allowed to fix the implementation in V8 or must they sit on it until everyone else patches JS in their browsers?
(These are sincere questions, not rhetoric. I am not a security professional, and I am fully aware that some things are more complicated in practice than they may appear from the comfort of an arm chair.)
So it's not as if there's an widely accepted principal of "patch as quickly as possible". There are tens, probably even hundreds, of terribly severe remote code execution bugs known to major vendors and not yet patched. Patching takes time and money. It's not instantaneous.
It is somewhat widely accepted that if people are actively exploiting a vulnerability, it should be disclosed. But if there were known exploits for this vulnerability, chances are Adobe wouldn't be sitting on the fix.
The moment one of the vulnerabilities is found “in the wild," the patch is automatically pushed into the wild, Adobe be damned.
First, how would a system that searches for exploits in the wild then releases patches for those vulnerabilities have a primary purpose of “putting pressure on Adobe?” Its primary purpose is to protect the users of its products from an exploit.
Second, help me understand why I should care about how hard Adobe’s team works. Are you saying they deserve our sympathy? Or implying that since they are smart and working hard, we cannot expect any better results than they are getting?
http://googleonlinesecurity.blogspot.com/2011/08/fuzzing-at-...
One of the exciting things about working on security at Google is that you have a lot of compute horsepower available if you need it. This is very useful if you’re looking to fuzz something, and especially if you’re going to use modern fuzzing techniques. ... We recently decided to apply the same techniques to fuzz Adobe’s Flash Player, which we include with Chrome in partnership with Adobe.
we cranked through 20 terabytes of SWF file downloads followed by 1 week of run time on 2,000 CPU cores to calculate the minimal set of about 20,000 files. Finally, those same 2,000 cores plus 3 more weeks of runtime were put to good work mutating the files in the minimal set (bitflipping, etc.) and generating crash cases. These crash cases included an interesting range of vulnerability categories, including buffer overflows, integer overflows, use-after-frees and object type confusions.
I would not be surprised if over half of this year's weeks fall under the case of having a vulnerability they have issued an advisory for and have yet to patch.
If you find out a vulnerability is being exploited in the wild, and already have a patch or technical description, you should release it. If one of the two parts commits a mistake and releases information about the vulnerability (like, for example, a patch that can be reverse-engineered), then all other involved parts should release what they have.
If they don't have a patch or if they aren't ready to release it, which seems to be the case here, Adobe should at least release technical details. These can be used to mitigate the impact of the vulnerability on unpatched hosts.
> "Even Google isn't well-served by this; not everyone updates their Chrome version immediately, especially updates like this one which require that you restart the browser (and all running browser instances)."
Protip: Updating Flash requires the same thing. In fact, updating Flash will shut down all kinds of apps you have running, including all Flash-capable browsers and even some Flash-reliant native apps.
There's potentially a multi-day window of opportunity for Chrome to get hacked, because the malware authors can release new exploits before everybody gets around to restarting their Chrome to pick up the patched version.
So malware authors learn about the new Flash security bug thanks to Google's aggressive patching, and then have perhaps days to exploit it before people get around to restarting Chrome and before Adobe gets around to pushing out a new Flash update.
So Google is aggressive about releasing critical patches, but Chrome is lazy about restarting to receive critical patches.
Not sure what the best way to handle that would be. I would certainly like to receive the patch ASAP. For critical updates Chrome should alert the user with a dialog like "it's critical that Chrome restarts now to keep you protected". For people like me who leave their Chrome running for days at a time, that feature could make all the difference. I might even prefer an option to automatically restart my Chrome to get critical updates.
I think it's safe to say that Flash is buggy as hell, and we would all benefit from the immediate installation of critical patches. I don't think Chrome is doing this yet.
One of these is much more likely to occur than the other.
In any case, Chrome's update mechanism promises to get more users patched, quicker, than Flash. Waiting for Flash is nonsensical.
By comparison, on Windows and OSX when there's a Flash update, the user will be notified when the update arrives.
So Chrome delivers the Flash patch really fast, but then doesn't notify users that they need to get it.
And Adobe and Apple deliver the Flash patch slowly, but the user is notified.
Neither of these situations is ideal. What I want is fast arrival of the patch, plus notification. I guess I will look for a Chrome bug on this.
Windows Chrome now has better update notification: http://crbug.com/27941
In April the update notification was further improved: http://crbug.com/71202#c24
OSX Chrome still needs better update notification: http://crbug.com/45147
There are different UI challenges on the Mac that have delayed the improvement there. No wonder I've been missing it.
The only new thing here is the staggered updates. This article takes the stance that this is a bad practice, and operates off of the assumption that malicious users will use the patch to create an exploit. The flip side is, of course, that there already is an exploit in the wild and now chrome users are safe.
The reality of the situation is that both are true. Someone malicious already has the 0day and someone is going to reverse engineer the patch. You'll never know which is the better option short of scanning every single.swf, trafficked over every protocol on the internet to do a statistical analysis of the incidence rate prior to releasing the patch as well as attempting to predict how many new malicious swfs will pop up after the patch before adobe releases. Oh and predict the patch application rate, as well as the probability of exploited users along the long tail.
Oh, and thats only if your definition of "best" is least users compromised.
What about the relative value of targets as a factor in determining which patch release strategy is the better option. The RSA attack used a flash exploit embedded in an xls. Is 500 patched boxes at a hypothetical-RSA averting an attack worth 500,000 grandmas slow on the upgrade train compromised?
Welcome to the world of responsible disclosure. Its easy to understand how to maximize damage, minimizing it damn tricky.
http://googleonlinesecurity.blogspot.com/2010/07/rebooting-r...
(tl;dr: 60 days for the vendor to it fix it).
Would like to know if they followed it in this case.