Tavis Ormandy’s public full disclosure of a Microsoft Help Center vulnerability has stirred up a storm of controversy, in which he has been burned at the stake by Microsoft and his own peers.
The Full-Disclosure Mailing List is hosted by Secunia to facilitate discussion of security issues. Archives of the list are mirrored by SecLists.org, which describes the Full-Disclosure list thusly:
An unmoderated high-traffic forum for disclosure of security information. Fresh vulnerabilities sometimes hit this list many hours before they pass through the Bugtraq moderation queue. The relaxed atmosphere of this quirky list provides some comic relief and certain industry gossip. Unfortunately 80% of the posts are worthless drivel, so finding the gems takes patience.
One such gem was Tavis Ormandy’s disclosure of a Microsoft Windows Help Center vulnerability on the 10th of June. Given the nature of the Full-Disclosure list and Microsoft’s security record, the only thing I initially found surprising about this vulnerability report was the depth of detail of the analysis, covering such issues as the merits and flaws of the Microsoft Help Center architecture as well as the educational tone of the report.
Over the next couple of weeks, however, a drama has proceeded to unfold that I found somewhat more surprising than that. The obvious, and expected, response from Microsoft came as no shock — a scathing attack on the character of the security researcher who discovered the vulnerability.
Microsoft, like many vendors, advocates a policy such vendors call “responsible disclosure.” This policy involves informing the vendor as quickly as possible, and informing anyone else effectively never, letting the vendor do the job of giving credit where it is due, and leaving users in the dark about the vulnerabilities that may affect them until the vendor gets around to patching them . . . some day. Given Microsoft’s record for vulnerability response, I am sure you will forgive me for lacking faith and confidence in the diligence and timeliness of corporate software vendors when it comes to vulnerability fixes.
As I previously pointed out when I asked How should we handle security notifications?, it may even be far more important to inform people they are vulnerable than to get the vulnerability patched. After all, given a poor track record for vulnerability handling, it should not take long for users to come to the conclusion that the best way to “patch” a given application’s vulnerabilities is to stop using it in favor of competing software that has a more secure design and gets more timely attention from the people whose job it is to keep the application secure. Specifically, I said:
Corporations have no right to hide behind any grace period. The customers — the software users and the people whose personally identifying information was accessed by malicious security crackers — have a right to know when their software is defective, when their finances are at risk, and so on. They need this information if they are to effectively limit the damage to themselves.
There are legitimate difference of opinion in the security community about how vulnerability notification should be handled. The two polar extremes are “responsible disclosure”, explained above, and “full disclosure,” wherein a security researcher publishes all information (often including proof-of-concept exploit code) for all the world to see. Within reasonable limits, I personally do not feel I can fault anyone along that spectrum between full and “responsible” disclosure; by reasonable limits, I mean limits like, “I will not wait eight years while you do nothing before disclosing this to the public.”
In fact, I see little reason to wait more than a couple weeks, if a security researcher wishes to give a vendor a reasonable amount of time to develop a patch. Whether disclosing proof-of-concept exploits before a patch has been developed (within reasonable time constraints) is really advisable is certainly debatable, but there are arguments for it based on a genuine concern for security, and demonizing researchers for doing so is entirely uncalled-for.
Still, Microsoft’s wholly unreasonable (and even childishly spiteful) response did not surprise me. At first glance, it may appear a very polished, professional piece of writing — and in fact it is, but its underlying motivation is clearly one of misdirection, casting blame, and generally behaving in a manner unbecoming to someone who pretends to adulthood.
The first sign of this is Microsoft representative Mike Reavey insisting on referring to Tavis Ormandy only by the phrase “Google researcher”, despite Tavis’ clear statements to the effect that while he is a Google employee, the Microsoft competitor itself had nothing to do with the discovery and disclosure of this vulnerability. Tavis Ormandy analyzed the vulnerability and developed a report for it on his own time, and credited a few other individuals for their aid when he asked for it.
Reavey goes so far as to call the work-around presented by the Full-Disclosure list report “the actual workaround Google suggested”, for a moment dropping any pretense of recognizing that it was Tavis Ormandy’s work, instead casting Google itself in as negative a light as possible. Rather than focus on the vulnerability and how to fix it, Mike Reavey chose to take the opportunity to try to create bad press for a competitor that was largely irrelevant to the entire episode.
Still . . . not surprising. It is unethical, spiteful, and dishonest, but hardly surprising.
The fact of the matter is that, like any extremely responsible security researcher should, Tavis Ormandy wanted Microsoft to agree to a deadline for development and deployment of a patch for the vulnerability he reported, and of course Microsoft would not agree to any reasonable deadlines after which Tavis would be free to tell the victims of Microsoft’s tardiness in addressing the matter that they were vulnerable to attack. As a result of Microsoft’s refusal, Tavis Ormandy elected to take Microsoft at its word (that there would be no timely response to the vulnerability) and inform the public himself so that people could at least attempt to protect themselves for however long Microsoft remained AWOL on the matter.
Microsoft’s response, in the person of Mike Reavey, paints a picture of someone acting on behalf of Google to give Microsoft a grand total of less than four days to produce a patch, when the truth of the matter was that an independent researcher who happens to be employed by Google (and clearly dissociated himself from his employer in his notification) gave Microsoft five days of his life trying to convince the corporation to agree to fix the vulnerability in under two months.
So . . . what do I find surprising?
What I find surprising is the manner in which supposedly independent security researchers parrot Microsoft’s character assassinations, resorting to casting aspersions on Tavis Ormandy, disingenuously linking Google to the entire fracas as if its founders were themselves responsible for the report to the Full-Disclosure mailing list, and completely inappropriate name-calling:
Yes, Tavis is a terrorist!
Really? Is this how far we have gotten from reasonable discussion? Do we really call people who disagree with us about vulnerability disclosure “terrorists”? Never mind the fact that Tavis Ormandy tried the “responsible disclosure” route before and waited seven whole months before giving up on Microsoft doing the right thing. When they flat-out refused to agree to any kind of reasonable timetable this time around, he only took the corporation’s representatives at their word and cut to the chase. For this, he is labeled a terrorist.
I am a strong believer in the importance of a community to keep the security profession honest. That community is necessary for peer review, development of ideas through discussion, and connecting people with complementary skill sets in ways that corporate software vendors would really rather never occurred.
Right now, I am sorely disappointed in the maturity, honesty, and fair-mindedness (to say nothing of the grammar skills) of the security community. There are some members of the community who defended Tavis Ormandy, and others who simply took a reasonable approach to deconstructing the falsehoods and misdirections of those who have jumped on Microsoft’s bandwagon, but even a sizable minority of members of that community taking a nearly point-for-point duplication of Microsoft’s approach to assaulting Tavis Ormandy’s and Google’s reputations is enough to make me question how long such a “community” can survive its own membership.