Responsible disclosure, the Microsoft way

This is a bug I've been following closely since last November when Cesar Cerrudo, the hacker who found it, got tired of waiting for a fix from Microsoft and published details during the MoKB (Month of Kernel Bugs) project.

Last month, when Bitsec's Joel Eriksson created an exploit for this two-year-old flaw and sold it for release in Immunity's Canvas point-and-click attack tool, I suggested that Microsoft just might scramble to get a fix out the door.

Imagine my surprise to find a patch for this flaw in MS07-017, the emergency, out-of-band update shipped last Tuesday to thwart the zero-day animated cursor (.ani) attacks.

In a month, Microsoft moved from this being a "design problem" that was going to be fixed "in a future service pack" to releasing a fix in an emergency update.

Interestingly, Cerrudo was not given credit for reporting the flaw because, in Microsoft's eye, he crossed the "responsible disclosure/full disclosure" line.

I asked Microsoft to explain its stance on crediting researchers, disclosure and its actions in this specific case and, after a detailed interview with two directors in the Microsoft Security Response Center -- Mark Miller and Andrew Cushman -- I'm still at a loss how Cerrudo can be described as the irresponsible party.

"We don't credit researchers who participate in full disclosure," Miller declared, chalking up that stance to a rigid policy to encourage the concept of "responsible disclosure," where the researcher reports a bug directly to the vendor and gives the vendor sufficient time to create, test and release a patch.

"Full disclosure is unacceptable because it puts customers at risk. We do appreciate the fact that Cesar did work with us for that period but, once he provided that information to the public, he increased the risk to customers," Miller said.

But, at what point does that element of responsibility shift to the vendor? (Remember, we're talking about getting a two-year heads-up from the researcher)

The MSRC's Cushman, who works closely on Microsoft's efforts to befriend a cynical hacker community, agrees that responsible disclosure only works if the vendor is actually responsive but he argues strongly that the company's overall track record proves that it goes out of its way to respond to flaw warnings.

Still, I interjected, in this case, you had two years to get a fix ready and didn't. You only decided to issue a fix after Cerrudo went public. In many respects, Cerrudo helped protect Windows users by going public and prodding you into releasing a patch.

"In this particular case, it was a complicated issue," Cushman explained. "The fix was relatively involved and had architectural implications so we decided it was something that was best addressed with a service pack. We were in communication with Cesar as to the implications and why we didn't address it with a bulletin. The ideal solution was that Cesar would come back to us, tell us he was having second thoughts and give me a chance to consider his argument. Instead, he chose to go public with the Month of Kernel Bugs release."

Miller was even more blunt: "Microsoft's point is really clear. Once someone puts customers at risk, we can't credit them. We never have and we don't intend to change that policy."

Again, I asked him to explain how Cerrudo was the one that put customers at risk when Microsoft knew about this for two years and chose not to release a fix.

"I hope you don't write that we were twiddling our thumbs, doing nothing with it for two years," Cushman interjected. "This was coded up to go out in a service pack. It's important to remember that this isn't a critical bug. It's something we rated as important. There's no risk of remote code execution."

"We made a decision a long time ago that this would be fixed. It was coming in a service pack. The public release of the details [during the MoKB) was what changed our minds. It wasn't a case of two years worth of engineering going into this fix.

This issue highlights why dialogue between vendors and researchers is an important thing. We weren't aware that Cesar was frustrated because he wasn't seeing an update. Maybe that's something we have to work on improving. We're always looking at ways to improve things," Cushman said.

"We know we're not perfect [but] our track record demonstrates that we do a pretty good job. There were a few cases over the last few years where we misdiagnosed or mis-triaged a security vulnerability. But, on the whole, i think we do a very good job," Cushman said.

Miller believes the concept of responsible disclosure is working very well, noting that about 75 percent of bug reports coming into Redmond are done responsibly.

But, as Cushman himself acknowledges, this only works when the vendor is responsive. In this instance, it failed. Largely because of Microsoft.