Google has a nice PR fluff piece trying to justify the actions of Tavis Ormandy, and like much of the analysis so far on the web it tries to play up the responsible/full disclosure debate. To begin with, while Full Disclosure is not necessarily irresponsible, there are certainly times where companies are so unresponsive or hostile to researchers that it may really be the only means of forcing a change, it often is. When the researcher is releasing the vulnerability without talking to the company, or the company disagrees with the timetable (and they are in a much better position to judge that than the researcher) but still intends to fix, it is pretty juvenile to self righteously release the exploit in the wild. The people hurt by that dont’ work at the company, they work at small businesses, or own home machines, etc.

However the discussion on responsible/full disclosure misses the point of what Tavis did, though Robert Hansen certainly grasped onto it. What Tavis, and Google (because as an employee his actions reflect on his employer, regardless of whether or not his is on the clock – that’s the way the real world works. If Steve Ballmer gorilla tossed a google employee through a wall during his personal time you can still bet it would implicate Microsoft despite how awesome the youtube video of it was), did was professionally unethical. To intentionally release exploits in competitor products breaches the professional civility that *should* be expected between two competitors in a polite society. That action leads not to companies competing on the merits of their respective products, pricing, and services, but by attacking competitor customers through the publication of exploits, which has several very chilling implications. It is one thing to smear competitor security in PR campaigns (even if both hypocritical and wrong, as Apple does – its great that one of the most common exploit paths in Windows is Quicktime. Way to create criticism Apple), but quite another to actively aid criminals in order to generate market advantage. That is not acceptable for any company to do to another, and speaking for my own company, my team will not hire any security professionals that come from an organization that endorses such a tactic, regardless of their technical merits. Professional ethics matter, most especially in our field.

And to nitpick a specific detail in Google’s post:

“For example, a design error needs more time to address than a simple memory corruption bug”

There is simply no such thing as a simple memory corruption bug. An EXPERIENCED security engineering team is well aware of the fact that statistically, if mistake was made in one place it was very likely made in other places in the code. We KNOW that people of all color hats reverse engineer client patch code to find what was fixed, and we KNOW they then use that knowledge to look for similar vulnerabilities – at least anyone who has gone to Blackhat in the past ever does. Releasing a patch that covers a single area of code, while not addressing adjacent areas where similar mistakes likely were also made, does not noticably help improve security. In fact you might be opening the door for a deluge of 0-days. Additionally, the more patches released the more likely customers are going to miss a patch. If you end up having to patch the same vulnerability that occurred in multiple places with multiple patches, a significant number of customers are going to remain at least partially exposed by missing patches. For every vulnerability there should be an analysis of other places the same mistake was made, and all of them should be simultaneously fixed. That takes time, and turns what should have been a simple vulnerability into a fairly significant amount of work. One can look at early mozilla patches prior to them building an experienced security group to see a litany of patches as a result of hyperfocusing only on a specific instance of vulnerable code.

Google, it reflects poorly that you either don’t understand, or don’t acknowledge that reality.

~ Joshbw