Google releases a fix for flash, before Adobe(securitywatch.pcmag.com)
securitywatch.pcmag.com
Google releases a fix for flash, before Adobe
http://securitywatch.pcmag.com/google/288014-google-patches-flash-zero-day-bug-jumps-the-gun-on-adobe-again#fbid=H3-jfJu-C9Z
9 comments
Just to be clear: while reasonable people can disagree about patch and disclosure timing, the point that this article makes isn't a fringe point. Virtually every vulnerability researcher goes through some kind of elaborate dance with vendors to coordinate the safest reasonable release of bugs and patches.
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.
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.
I’m idly imagining a massive Google HoneyFarm with browsers that examine payloads from known “harmful sites” and spam or phishing emails.
The moment one of the vulnerabilities is found “in the wild," the patch is automatically pushed into the wild, Adobe be damned.
The moment one of the vulnerabilities is found “in the wild," the patch is automatically pushed into the wild, Adobe be damned.
Google did this just recently:
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.
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.
If Google wanted to spend a lot of effort just to hot-foot one of the harder working teams in software security they could indeed build a system whose primary function was to put pressure on Adobe.
I’m confused by the relationship between your statement and my imaginary HoneyFarm.
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?
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?
I think Adobe's team deserves more sympathy than it gets. I'm not making any comment about Adobe- the- company, which I know very little about.
Just this year there have been several Flash or Flash/Acrobat vulnerabilities that were seen in the wild and Adobe said the patch was two weeks out.
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.
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.
I'm sure Google is not doing stuff like this for fun. I'm just saying the point the article is making is not crazytalk.
This is why it's bad having a cross-platform technology that is proprietary. It's too much to handle for a single company and make it work right on all platforms. When it's open-source, there can be at least one company with its own implementation on each platform, and get it to work right because they have less to handle.
This is obviously a matter of opinion, so here is mine: Patches and information pertaining a vulnerability should be released in a coordinated way or as soon as there is evidence that information about the vulnerability is already public. By public I mean that has escaped the closed circle of the vendor, and in the case of a reported vulnerabilty, also the reporter.
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.
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.
Google probably didn't do it for fun but rather because it was being exploited in the wild and they were unwilling to delay protection for their users. As a user I appreciate this. Adobe needs to get their patch cycle and updating to Google's level ASAP.
What BS:
> "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.
> "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.
I think you missed the point.
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.
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.
How is that any different to Adobe releasing a patch? Chrome updates a darn site more often than Adobe products do. So surely this is a problem regardless who releases?
Aren't Adobe's patches pushed to everybody and installed immediately upon reception? Without waiting for the user to manually accept or restart, I mean. I don't know for sure.
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.
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.
No, they aren't, that's my point. Neither Chrome nor Flash can expect patch pickup in the order of days - in fact, Flash updates (on Windows and OSX at least) require user intervention, whereas Chrome will do it at browser restart.
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.
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.
I don't think "nonsensical" is the word you want to use here. The majority of the world's susceptible Flash users are not running Chrome. You can reasonably assert that it's not Google's problem that their patch discloses the flaw without providing those people with a usable recourse from it, but it's harder to assert that it's not a problem at all.
My point is when there's a critical Flash update, Chrome doesn't notify me ASAP. So my Chrome might be open for days with a vulnerable Flash without me knowing that it's time to restart. This is why I check About Chrome almost daily (kind of an annoying obsession).
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.
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.
I dug around in the Chrome bug database a bit and learned.
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.
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.
This is another area of the disclosure debate that will never get solved.
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.
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.
I think it would serve the web well if Google bought Flash from Adobe and simply integrated an ActionScript 3.0 rendering engine into WebKit as an alternative language to Javascript.
They clarified their responsible disclosure policy here in 2010:
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.
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.
If it's a zero day vulnerability then the method to exploit it is already in the wild. Anyway, if this is anything like some of the previous vulnerabilities that chrome patched a few days before Adobe, it's just a case of Adobe's code going through a faster SQA process at google than it does at Adobe. Adobe obviously doesn't have a problem with the practice, so why should PC mag?
I think there is a solution to this on the iPad and Windows 8 (Metro UI).
[deleted](2)
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.)