Things are getting curioser and curioser of late at Microsoft. The company is no longer the punch line for every joke in the IT security industry, but now the lessons the company learned in the last 10 years about dealing with researchers and making product security a priority are falling by the wayside.
Microsoft security officials have spent the better part of the last decade working hard on several fronts to convince partners, security researchers and customers that the company is serious about security. That effort involved huge changes to the way that Microsoft designs, develops and deploys software, as well as the way that it works with the security researchers who find vulnerabilities in its applications.
Microsoft executives reached a detente with the researcher community, convincing many researchers to disclose new bugs privately rather than on a mailing list or blog post. The company even launched an internal conference called Blue Hat every year to which they invite top researchers, many of whom are complimentary about the process of working with Microsoft now.
But cracks have begun to appear in that veneer in the last few months. One example is the stale system that the company uses to rate the severity of vulnerabilities. The system is nearly 10 years old and has undergone only minor modifications in that time, failing to keep up with what matters in vulnerability disclosure, experts say.
“If I were writing a rating system, it would be much more refined,” Charlie Miller of Independent Security Evaluators told Threatpost’s Paul Roberts regarding the rating system. “As someone who finds bugs for a living, I have to assess
the ease of exploitation of bugs all the time, and it is difficult, and
subjective, but I have to do it in order to move on.”
The company’s most noticeable departure from its playbook has come with Microsoft’s very public and unflattering spat with researcher Michal Zalewski. Zalewski released cross_fuzz, an application testing tool he used to discover exploitable holes in Internet Explorer 8 and other common Web browsers.
As they often are in cases like this, the facts are in dispute. But both sides in this argument seem to agree on this account of events: Zalewski notified Microsoft in late July about the crash that he’d found, sending the Microsoft Security Response Center a copy of cross_fuzz so the company’s experts could try to reproduce the condition. The MSRC responded, asked for more information and Zalewski then sent them an updated version of the fuzzer. After the first week of August, Zalewski says he didn’t hear from the MSRC again until late December.
At that point, Zalewski contacts the MSRC again and reiterates that he’s planning to release the tool in early January. The MSRC officials say that they couldn’t reproduce the crashes Zalewski talked about and that they started to write a response in August but never sent it. They then say that maybe the reason they can’t reproduce the crash is a difference in the code of the different versions of the fuzzer. But that’s ruled out quickly as one of the MSRC officials is able to reproduce the crash.
After that, it gets a little messy. But the salient bit is that it seems the MSRC sat on Zalewski’s report for more than four months after initially not getting the same result he did. This isn’t unusual: vendors often have trouble reproducing the results of a bug that a researcher sends them and will typically ask for help from the researcher if that’s the case. Microsoft did that in this instance, but not until four months after the initial notification, and only then after more prodding from Zalewski and the reminder that he planned to release cross_fuzz in a couple of weeks. That apparently created a sense of urgency at the MSRC and they asked Zalewski to delay the release of the tool. He declined.
There’s nothing there that we haven’t seen several times before. But the long delay between the time of Zalewski’s initial contact with the MSRC and the eventual confirmation by one of the Microsoft officials is disheartening. Microsoft, and the MSRC specifically, have a huge amount of resources at their disposal. The idea that they either didn’t have the time or the resources to investigate Zalewski’s report fully and get to the point where they could reproduce the crash is weak. Not only did Zalewski send them the technical details, he sent them the fuzzer that found the crash, as well.
As Zalewski noted in his timeline on the cross_fuzz release, even Microsoft’s eventual response was lacking. Roughly five months after getting the first release of the fuzzer, Microsoft told Zalewski they were able to find the same crash with the original version. That’s a lifetime. Here’s the email response from Microsoft to Zalewski:
“Dave ran cross_fuzz_randomized_20100729.html last night and was able to hit a crash too. The IE team did exhaustively run the fuzzers but were unable to find the same crashes that you and Dave are now able to identify. I can’t really say as to why we are able to hit some of these conditions now rather than before but please know that this was not intentional.”
Microsoft disputes Zalewski’s version of events, not surprisingly, saying that the original version of the fuzzer he sent in July didn’t find any crashes in IE. If that was the case, it’s unclear why Zalewski would’ve sent the tool to Microsoft at all.
“On December 21, a third variation of the tool known as cross_fuzz_randomized_seed.html was sent to Microsoft along with information on a potentially exploitable vulnerability in Internet Explorer. We tested this version and quickly found some issues. Working with Zalewski, we were then able to verify his report that a crash could be found with the version of the tool he reported on 7/29. It is important to clarify that neither Microsoft or Zalewski found this issue in the July timeframe. After reviewing the new version of the tool and the crash report, we requested that Zalewski hold the public release of the new version of the tool and information on the specific vulnerability found in December until we could investigate further. We specifically told Zalewski we were fine with him publishing the two versions of the tool reported in July,” Jerry Bryant, group manager in the Trustworthy Computing Group at Microsoft said in an email.
Microsoft’s fumble in this case is all the more concerning because not only is there an exploitable crash in Internet Explorer, but Zalewski discovered during his research on cross_fuzz and the IE bug that some unknown parties in China also apparently know about the crash. If that’s so, then users are at risk of attack and Microsoft won’t fix that bug in this month’s Patch Tuesday release. US-CERT has published an alert about the bug, too.
The subtext to all of this, of course, is that Zalewski works for Google. Zalewski published the research on his own blog and made no mention of Google in his report or anywhere in his research, but Microsoft officials know where he works, as do many people in the security industry. Bryant mentioned it in his statement. But it’s hard to believe that Microsoft would have slept on Zalewski’s report and intentionally put users at risk just to make a point to him and Google. It just doesn’t make sense.
What makes more sense is that Microsoft dropped the ball on this. And then kicked it a couple of times trying to pick it up. That happens, but for an organization of Microsoft’s size, influence and importance it’s troubling. The company has an efficient, well-honed response process that’s been modified and improved over time, but the situation with Zalewski’s report looks like a misstep that could have–and should have–been avoided with some better communication.
