28 ms·

So is the argument that Google should leave the vulnerability unpatched in its own browser until Adobe get around to patching it in their plugin for other brows

So is the argument that Google should leave the vulnerability unpatched in its own browser until Adobe get around to patching it in their plugin for other browsers, so as not to publicize the existence of a vulnerability? 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.)

tptacek 15y ago
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.
- raganwald 15y ago
  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.
  - tptacek 15y ago
    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.
    - raganwald 15y ago
      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?
      - tptacek 15y ago
        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.
  - cpeterso 15y ago
    Google did this just recently: http://googleonlinesecurity.blogspot.com/2011/08/fuzzing-at-scale.html 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.
- mukyu 15y ago
  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.
  - tptacek 15y ago
    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.
pvarangot 15y ago
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.
nextparadigms 15y ago
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.

tptacek 15y ago

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.

raganwald 15y ago
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.
- tptacek 15y ago
  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.
  - raganwald 15y ago
    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?
    - tptacek 15y ago
      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.
- cpeterso 15y ago
  Google did this just recently: http://googleonlinesecurity.blogspot.com/2011/08/fuzzing-at-scale.html 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.
mukyu 15y ago
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.
- tptacek 15y ago
  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.

pvarangot 15y ago

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.

nextparadigms 15y ago

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.