June 20th, 2007

Skeletons in Microsoft's Patch Day closet

Posted by Ryan Naraine @ 8:18 am

Categories: Botnets, Browsers, Data theft, Exploit code, Hackers, Metasploit, Microsoft, Patch Watch, Pen testing, Responsible disclosure, Spyware and Adware, Viruses and Worms, Vulnerability research, Zero-day attacks

Tags: Security, Vulnerability, Microsoft Corp., Bulletin, Ryan Naraine

Last Tuesday, when Microsoft released the MS07-030 bulletin to fix a remote code execution hole in Visio, the first line in the executive summary caught my attention:

This important update resolves two privately reported vulnerabilities in addition to other security issues identified during the course of the investigation. (emphasis mine)

This is the first time I’ve seen Microsoft prominently admit to silently fixing vulnerabilities in its bulletins — a controversial practice that effectively reduces the number of publicly documented bug fixes (for those keeping count) and affects patch management/deployment decisions.

[ SEE: Windows vs Linux security report card ]

When a flaw is reported by an outside researcher, the MSRC (Microsoft Security Response Center) routinely conducts a comprehensive audit of the surrounding code base to find and eliminate any potential problem areas. The problem, according to security research professionals, is that Microsoft keeps a tight lid on the details of those internally discovered issues, a move that makes it difficult for an IT administrator to make an informed patch deployment decision.

Microsoft’s stance is that publicly disclosing the details of flaws found during an internal investigation puts more ammunition into the hands of bad guys.

Mark Griesi, a program manager in the MSRC, explains the company’s patching/disclosure policies:

If the attack scenario and recommended customer actions provided in our security bulletins is different for an issue found through our internal investigation, we’ll document the risk according to the most severe internally found issue within the vulnerabilities details for the externally reported issue.

For almost all cases, since the internal investigation is based off of the external report, the resulting attack scenarios are similar. So they don’t require a separate call-to-action or separate documentation for customers.

In an interview, Griesi notes that this isn’t always the case, pointing to the MS06-023 bulletin as an example of vulnerability fixed — and publicly documented — even though it was discovered internally.

Still, Griesi admits that Microsoft will not open a new CVE entry to spell out exactly what is being fixed. This, Griesi argues, gives malware writers too much information about the location of weak spots in the code base and puts Microsoft customers at higher risk.

On the other hand, white hat hackers warn that silent fixes is a dangerous practice because exploit writers already have the tools to reverse-engineer a Microsoft patch to find all the silently fixed issues.

“You’re not fooling exploit writers with silent fixes. You’re only fooling your customers,” says Marc Maiffret, co-founder of eEye Digital Security.

Maiffret explains the Patch Day routine. First, the bad guys:

1. They download Microsoft patch.
2. They expand the patch and find what files have been modified by the patch.
3. They grab the same binaries from an unpatched OS.
4. They run the two binaries, new/old, through a binary diffing utility.
5. They analyze the few changes to identify which are security fixes or not.
6. They write exploits for *all* vulnerabilities regardless of what is in Microsoft’s bulletin.

Now, this is what happens in a typical enterprise, where IT guys are scrambling to get patches prioritized and deployed:

1. They review Microsoft’s security bulletin.
2. They make a risk assessment based on the vulnerabilities publicly documented by Microsoft.
3. They decide the patch is not as important, based on the public information released by Microsoft.
4. Their system becomes compromised because they didn’t prioritize correctly and one of the silently fixed vulnerabilities was easier to exploit for the bad guy. Unfortunately, IT guy never knew that.

HD Moore, a hacker who knows a thing or two about writing exploits, agrees with Maiffret.

“I have been arguing with the folks at MSRC for years about this. They take the approach that bringing attention to the flaw will make it more likely to be exploited. My view is that by not bringing attention to it, they are leaving their customers in the dark and making it easier for a repeat of the WMF or ANI attacks,” Moore said in an interview.

“Without knowing what was fixed or how it can be exploited, administrators and security professionals alike are left in the dark,” he added.

Another negative side effect of silent fixes comes when third-party vendors incorporate code from Microsoft but are not notified when that code is buggy. In these cases, the vulnerable code in the third party product is never fixed.

The absence of documentation also hurts IPS (Intrusion Prevention Systems) vendors that rely on vulnerability information to create signatures to block attacks.

eEye research engineer Andre Derek Protas sees the note in the MS07-030 bulletin as a sign that Microsoft has “taken a baby step” to admit that they’re silently fixing vulnerabilities.

“[Now] they need to take the next step and start informing customers and security vendors if those silently fixed vulnerabilities were more dangerous than the ones they reported. Unfortunately they don’t,” Protas said.

Microsoft’s Griesi said the software vendor is always reviewing feedback from customers to improve its security response process.