Google vs. Microsoft: The battle of Ormandy

analysis
Jul 22, 20106 mins

A recent incident has divided the security community over what constitutes "reasonable" disclosure of security vulnerabilities

Software developers should never take reports of security vulnerabilities lightly. But to ignore a vulnerability to the extent that you won’t even commit to a timeframe to fix it is utterly irresponsible.

That’s how Google information security engineer Tavis Ormandy saw it, at least. So when Microsoft hemmed and hawed at the critical security bug he discovered in the Windows XP help system, Ormandy took matters into his own hands. He published a full description of the vulnerability to the Full Disclosure security mailing list, including proof-of-concept attack code.

[ Stay up to date on key software development trends in InfoWorld’s Developer World newsletter. ]

The result, predictably, was a firestorm. Microsoft publicly condemned Ormandy’s actions, claiming the disclosure “makes broad attacks more likely and puts customers at risk.” Since then, real-world exploits of the bug have begun to appear. In a blog post last week, Graham Cluley, a senior technology consultant for security vendor Sophos, again berated Ormandy, asking, “Do you feel proud of your behavior?”

Microsoft has since published a fix for the vulnerability, but the incident has left the security community deeply divided. Moreover, it raises important questions for software developers. How should developers handle security vulnerabilities when they are reported by customers? What’s reasonable procedure for addressing them? And how should they react when their own customers seemingly become their worst enemies?

When researchers attack Ormandy maintains that his actions were not only justified, but necessary. When he first approached Microsoft regarding the vulnerability, he hoped the software vendor would agree to produce a patch within 60 days. But when his negotiations with Microsoft employees dragged on for five days and Microsoft still had not committed to any kind of patch schedule, he became frustrated with what he saw as dangerous negligence on the Redmond-based vendor’s part. Only then did he make the decision to go public.

That wasn’t fair, say Microsoft reps. Had Ormandy waited, Microsoft would have been able to commit to a formal schedule the following Friday, just six days after learning of the vulnerability. Instead Ormandy jumped the gun, rendering any further discussion moot.

But while Microsoft and critics like Cluley want to hold Ormandy personally responsible for the exploits that have appeared since he made his disclosure, that’s not really fair, either. It’s true that security researchers weren’t aware of any exploits of this particular vulnerability until now, but then why would they be? They weren’t even aware of the vulnerability until now. That’s no guarantee that malicious hackers hadn’t already added it to their arsenals.

Nor was this the first time Ormandy took the controversial step of disclosing a security flaw publicly. He’s well-known in the security community, and earlier this year he used a similar tactic to pressure Oracle into fixing a dangerous Java vulnerability. Oracle patched that flaw in just six days. It seems unlikely that Microsoft would have issued a patch for this latest vulnerability as soon as it did had it not been under similar pressure.

The 60-day patch guarantee For its part, Google seems to approve of Ormandy’s actions. In a blog post this week — co-signed by Ormandy and six other researchers — the Google security team reiterates its belief that 60 days is a “reasonable upper bound” for fixing “genuinely critical” vulnerabilities, claiming, “We of course expect to be held to the same standards ourselves.” The post stops short of recommending rapid disclosure if a vendor seems to be dragging its feet, but encourages the industry as a whole to “[create] pressure toward more reasonably-timed fixes.”

For many software developers, however, 60 days might seem too ambitious, particularly when it comes to fixing vulnerabilities in complex, server-based software. Security patches must be designed, implemented, rigorously tested, and then packaged for deployment. Occasionally they may need text localized into multiple languages before they can be distributed. A company as large as Microsoft might reasonably be expected to have the staff and resources necessary to guarantee a 60-day patch window, but not every software vendor is so fortunate.

Still, developers should beware complacency. Many customers are likely to think 60 days is far too generous. After all, they are the ones who are at risk when vulnerabilities go unpatched. What’s more, companies typically must follow their own testing and validation procedures for new patches before deploying them, which adds to the time it takes to fix a vulnerability once a patch has been issued. The sooner a software vendor is seen to respond to a security issue, the more confidence its customers will have that their interests are genuinely being addressed.

Raising the alarm or simple blackmail? The more troubling issue for many developers is the manner in which Ormandy made his disclosure. He could have waited the full 60 days — a “reasonable” period of time, by his own admission — before publishing the exploit. Instead he went ahead and made his disclosure, seemingly out of frustration that Microsoft wasn’t paying enough attention to him. That raises legitimate questions as to how much input customers should reasonably expect to have regarding software vendors’ procedures and practices. Some critics have gone as far as to describe Ormandy’s actions as “blackmail” — and it surely doesn’t help matters that Google and Microsoft are bitter rivals.

The Windows XP Help vulnerability is now closed, but within the security community the Battle of Ormandy has only just begun. The issue of what constitutes “reasonable” disclosure will resurface again and again in the coming months as new vulnerabilities are discovered. But whatever your own opinion of Ormandy’s approach, there’s no escaping that security vulnerabilities are a fact of life in the software business. Developers would be wise to take heed of this incident and plan accordingly.

While Ormandy was perhaps overeager in disclosing this vulnerability, Microsoft also made mistakes. It failed to appreciate the seriousness of the bug in Ormandy’s view and it failed to keep the lines of communication open as it decided upon a course of action. Perhaps it simply thought it was too big a company to have to listen to one lowly customer. But if that attitude backfired for Microsoft, smaller software vendors certainly can’t afford to make the same mistake.

This article, “Google vs. Microsoft: The battle of Ormandy,” originally appeared at InfoWorld.com. Read more of Neil McAllister’s Fatal Exception blog and follow the latest news in programming at InfoWorld.com.