Original URL: https://www.theregister.com/2006/01/13/security_wmf_microsoft/
Zero-day WMF flaw underscores patch problems
Countdown to what?
Posted in Channel, 13th January 2006 12:24 GMT
For four days in January, network administrators and security-savvy home users had a choice: download and install an unofficial open-source fix for the critical flaw in the Windows Meta File (WMF) format, or wait an estimated week for an official patch from Microsoft.
With security experts warning about the spread of exploits for the flaw in Microsoft's Windows operating system, tens of thousands of people downloaded the patch from the website of security software developer Ilfak Guilfanov and other websites that hosted the file, according to numbers provided to SecurityFocus.
The quick release of the patch showed the power of community-created code, but also the pitfalls. While source code accompanied the patch and Guilfanov made it easy to uninstall, the decision to install the patch came down to a single question: did the user trust the software developer, Ilfak Guilfanov?
"The patch was caveat emptor - let the patcher beware," said Richard Ford, associate professor of computer science at the Florida Institute of Technology. "Users are not sophisticated. It is hard for them to tell the difference between a genuine third-party patch developed by a white hat, and a program created by a black hat that looks like a patch."
A day later, several security groups vouched that the patch did what Guilfanov said it did, reducing the risk of an untrustworthy patch. Yet, even the patch's creator recognized the inherent problems in the situation. Having to make a decision about whether to trust a third-party patch should not be necessary in order to protect systems.
"As a general rule, (third-party patches) should not be applied," Guilfanov said. "The current situation was, in my perception, a bit different. First there was the danger, then I saw a relatively simple and clean, risk-free fix. If I could help my knowledgeable audience - who could do their own testing - why not? People are postings exploits all the time, why not post a solution for a change?"
The unofficial patch debate underscored the problems with relying on software fixes to secure systems. While Microsoft released its official patch for the problem last Thursday - five days early - attackers had already started using the vulnerabilities in the Windows Meta File (WMF) format - putting the vast majority of users at risk. The situation emphasized the fact that neither Microsoft's patches nor community-created fixes will ever be able to defeat the threat of a zero-day attack.
"Speeding up the patch process is never going to solve the problem, it is never going to be fast enough," the Florida Institute of Technology's Ford said. "We need to be investing very heavily in zero-day defenses, because another zero-day will happen. There is a lot of talk about whether (the software vendor has) gotten the patch out in time, but the real conversation should be about risk removal, not risk mitigation."
However, even in the best case, Microsoft may not be able to shave much more time off its response.
The software giant's delay in getting a patch to users was mainly due to quality control. The software giant had a patch candidate in less than 24 hours, but testing the patch against all its operating systems, as well as popular applications, took far longer. And, if the company had to make the choice all over again, it would still make the same decision, because breaking even a small number of systems' functionality is unacceptable, commented Kevin Kean, director of the Microsoft Security Response Center (MSRC).
"Let talk about the consequences of someone not having confidence in your patch," Kean said. "If Microsoft blows it, if people cannot trust our patches, they will not deploy them. It is critical that people have confidence in our patches, and that has been built into our ethos."
The software giant put more than 200 people on fixing the flaw and testing the patch, Kean said. The company's product teams vetted hundreds of applications to make sure that the patch caused no conflicts. As a result of the all-out development effort, Microsoft released the patch nine days after first learning about the vulnerability.
That may be the fastest the software giant has turned around a fix on a widespread software flaw. In a survey of security advisories released by Microsoft in the past three years, the Washington Post found that Microsoft has taken longer to fix vulnerabilities privately reported to the company, but has shortened its time to respond to public disclosures, which includes zero-day attacks. Microsoft took three months on average to fix issues privately disclosed to the company in 2003, a response time that shot up to 4.5 months in 2004 and 2005, according to the analysis. Yet, the company response to a publicly disclosed flaws has quickened, from 71 days in 2003 to 46 days in 2005.
The survey also found that Microsoft has apparently been successful in convincing security researchers to disclose vulnerability information to the software giant first. In 2003, the company learned about eight critical vulnerabilities through public disclosure, but that happened only half as many times in 2005, according to the Washington Post analysis.
Yet, those numbers may miss a critical trend in who is finding vulnerabilities. Increasingly, zero-day vulnerabilities are not being disclosed at all by those who find them, generally attackers bent on using the flaw to compromise a small number of high-value targets, said Mike Puterbaugh, senior director of product marketing with network protection firm eEye Digital Security.
"Anyone with a zero-day is going to use it for a specific purpose," Puterbaugh said. "They are not going to go after my grandmother. They are going to use it to go after Citigroup, a government contractor or a university."
That means that companies will increasingly have to worry - not about the potential zero-day attacks that make the headlines - but the ones that are targeted at small groups, a situation that makes patching an ineffectual defense, Puterbaugh said.
It's a threat that worries many companies, so much so that "zero-day defenses" has become a buzzword for the industry and new companies have sprung up to meet the need for new technology.
One such company, network security firm CounterStorm, has found that security managers are eager to find solutions to the zero-day issue.
"We have yet to meet the chief information security officer who is not worried about zero-day attacks and companies are freeing up the budget to deal with the problems," CounterStorm CEO Gil Arbel said in a recent interview.
Other companies see zero-day defenses as a way to free themselves from the chaos of emergency patches. A major benefit of deploying security technologies to defend against zero-day attacks is that firms can patch on a regular schedule. Continental Airlines, a client of eEye, has moved from patching multiple times a month to once a quarter, said Andre Gold, the director of information security for Continental.
Reducing the amount of time spent patching is as much a benefit as protecting against zero-day attacks, Gold said. Patching is not a security activity, but a system administration activity - playing continual catch-up with the legion of black-hat attackers is not good security, Gold said. Even Microsoft's monthly patches are too frequent for the company, he said.
"The ad-hoc scenario kept us in chaos around here," Gold said. "The monthly frequency allows us to schedule resources, but that is still too frequent for us because it does not allow us to do regression testing."
Zero-day attacks will not go away, according to Tom Liston, a handler with the SANS Institute, an education and training organization. Liston had recommended that people deploy the unofficial patch from Guilfanov as an emergency measure.
No operating system will be free from flaws, but the fact that Microsoft has to retain potentially insecure code to support backwards compatibility makes it more likely that the security community may face a similar situation to the vulnerability in the Windows Meta File format, he said.
"The whole issue here is caused by backwards compatibility issues," Liston said. "Not only does Microsoft have to support code for Windows, but also code that goes back 15 years and that is not going to change."
This article originally appeared in SecurityFocus
Copyright © 2006, SecurityFocus