Responsible disclosure, the Microsoft way

Responsible disclosure, the Microsoft way

Summary: A few weeks ago, I wrote about a Windows kernel vulnerability that was reported to Microsoft on October 22, 2004 and remained unpatched for more than two years. 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.

SHARE:
TOPICS: Microsoft
135
A few weeks ago, I wrote about a Windows kernel vulnerability that was reported to Microsoft on October 22, 2004 and remained unpatched for more than two years.

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.

Topic: Microsoft

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

135 comments
Log in or register to join the discussion
  • "it's not a problem until others know about it"

    So it is true; Microsoft actually does copy Apple in all respects.
    GuidingLight
    • It's been...

      A Microsoft practice since day one. Also of note, Microsoft slips in a few "extra"
      goodies. Like fake error messages, for those that use competing products. So
      Microsoft has been doing it longer and also abusing the end user even worse.
      Rick_K
      • Fake error messages?

        That is such an "urban legend" I'm surprised people still believe it.
        John Zern
        • No urban myth

          Sorry, but I saw one of Microsoft's fake error messages.

          One of the services offered by the company I was working for in the mid 80's was the building of custom XT and AT clones, with every component specified by the customer, including the OS.

          Most customers wanted DR-DOS with Windows 3.1 on top. It became impossible to fulfull customer's wishes because at some point it became impossible to install Windows 3.1 on top of DR DOS. The reason? A fake error message ("Incompatible DOS version") and the end of the Windows install. The "fix"? Install Microsoft DOS 3.3

          - Yes, Microsoft started lying for profit all those many years ago ...
          whisperycat
          • Doesn't sound right

            First of all, there was no Windows 3.1 in the mid 80's and virtually any machine running Windows 3.x would have been running Dos 5.x or 6.x

            As for DR-Dos, if they'd provided a tool similar to MS's setver, I'd think you could have worked around it. I know that MS included the tool so that progs that didn't work with dos 5.x + would work.

            I certainly wouldn't put it past the MS of the 90's (esp prior to the win9x release), but I doubt it still happens.

            Either way, MS had no obligation to let Windows work on DR Dos.
            notsofast
          • Re:Doesn't sound right

            It not only doesn't sound right it is complete garbage. There was no issue at all installing Windows 3.1 ontop of DR Dos. I did this very thing for all the computers i built at that time and there was no such error message. Unless you were running Dr Dos ver 3.0 or older
            alanon5@...
          • "...complete garbage..." Huh?

            [i]There was no issue at all...Unless you were running Dr Dos ver 3.0 or older.[/i]

            Ummm, so there WAS an issue after all. WTF is your point?
            Spoon Jabber
          • reply to spooner

            Dude, why don't you do a Google search. In 1991 (windows 3.1 came out in 1992)DR-Dos was on VERSION SIX!!!. Are you actually going to whine about them not making sure the OS would work with an out of date version of an alternative OS (the first version of DR-Dos was 3.4)?

            To the original person who made the false claim, that error, as it turns out, was only in a beta version of 3.1 (and was easilly bypassed (source Dr. Dobbs Journal http://www.ddj.com/dept/windows/184409070;jsessionid=WXIZQJJ1AQ1WAQSNDLRCKH0CJUNN2JVN?pgno=4)

            It was removed from the final release and regardless, DR-Dos released a patch for it around the time of 3.1's release (as they assumed it'd still be there).

            Bottom line is for anyone using a RTM copy of 3.1, there was no bug. But thanks for telling the world that your company installed pirated beta software on customer's machines.
            notsofast
          • Not so fast, really

            My response was to the poster above mine, simply to point out that there did seem to be SOME issue, and the post was contradictory to itself, he said "complete garbage", "no issue at all", "unless..."

            And, if you read the other posts about the court case it seems that there was at least something to it, so my point is, speaking in absolutes...not a good idea.
            Spoon Jabber
          • Former POS(personal operating systems) support engineer here...

            Yes, there was a message in windows 3.1 and WfW 3.1x installs and installers if you tried to install it on dr-dos. you got an "Unsupported DOS version" error message, however it was not long before that check was commented out in the code (although the error message could still be found using "strings" or a similar package) I handled calls from people that had "upgraded" their dos to DR-Dos and got the error message. the suggested fixes were 1- return to MS or IBMPCdos 2 - there was an undocumented command line switch for the installer and the windows launcher that made it NOT check the version string from the OS. 3- ship the customer new install media that had the check removed and have them reinstall.

            the official story was that dr-dos was returning an invalid version string (which is plausable) to the installer and to the windows executable. however we were discouraged from experimenting and looking for ourselves.
            geoffr@...
        • The court evidence says otherwise

          Check out El Reg's summation of some of the motions and documents in the MS-Caldera trial. It discusses more than one apparently "false" incompatibility, and a deliberate attempt to make Win3.1 incompatible

          http://www.theregister.co.uk/1999/11/05/how_ms_played_the_incompatibility/
          brendthess
          • I believe you but let's keep the train on the rails

            Windows 3.1 was a long time ago, grass grows, weeds come up, die and new ones are taking their places. These issues are old, dated and not really very relevant as MS has been sued more times than I can count since that happend. Let's keep this train on the track and relate to what the issues are now. The problems that Microsoft has are more than any one man could list in a full day. The bigger the programs, the more holes and potential problems there are going to be. Vista is for some the greatest thing since Carter's little liver pills but for others, it really is a breaking point as many are no longer going to support Microsoft. Good, bad or whatever you want to say, it won't change the fact that Mac and Linux has increased users supporting their OS of choice.
            intrepi@...
    • No . . .

      . . .they're not up to Apple's performance standard . . !
      critic-at-arms
    • It's not a problem until somebody make's it one

      I'm waiting for Microsoft's new Leopard OSx as I heard it's going to be a more secure version of their newest Vista Ultimate. I just know Apple will want to try and copy this OS and try to brand it as their own.
      intrepi@...
  • Damn if you do, damn if you don't

    Seems there was no way to win in this situation. I do see how Cesar Cerrudo did in a way put customers at risk. By him making the vulnerability known, it allowed malicious hackers the chance or option for that matter to exploit it. But at the same time, 2 years, that is far too long to ignore an issue. I feel like I am beating a dead horse when I say it, but Microsoft needs to address issues at a faster pace. As far as I am concerned they did more damage holding off patching the issue then Cesar did making it known. Go figure though, when Microsoft is questioned, they of course get defensive.
    Brandon Dixon
    • Mostly Agree

      2 years is too long, but given that it wasn't exploited until Cesar told everyone about it, it's debatable who caused more damage, but 2 years is really too long.

      That said, how often do these problems go unpatched for this long?
      My guess is this is an exception to the rule....if it's not, then I have to wonder just how good the bad guys are if they aren't exploiting these things until a good guy explains it and perhaps even provides sample code.
      notsofast
      • Strongly Disagree

        "given that it wasn't exploited until Cesar told everyone about it"

        I have a huge problem with that statement. It makes huge assumptions that are big enough to allow a whole planet through. How do you know that this particular flaw has not been previously exploited. You are assuming that the so called blackhats hadn't found it and exploited it simply because no one talked about it. Second assumption that is tied to this one is that only exploits that are available in the internet are indicative of flaws identified. So, what that means is that any flaws with no publicly available exploits are unknown. Flaws should be fixed once identified. period. it is not only the good guys who are researching vulnerabilities in systems. Some of the other guys have a huge incentive to not disclose flaws that they discover so that they can exploit them.
        goxk@...
    • Damn if you do, damn if you don't

      That's why they get paid the BIG bucks. Simple.
      sackbut
      • That's "damned", not damn (NT) :)

        :)
        Spoon Jabber
    • Vista is a huge OS to defend and no easy task

      If it took a year longer to get Vista to market, it should give you some perspective as to why it takes them so long to provide fixes or security patches as this OS is a huge piece of realestate with a lot of pickets missing in it's defences. You can question MS all you want but I found it to be a waste of time to even try to get anyone at Microsoft to answer anything. Their policy is sell em what we got, they like it, fine, if they don't, tough cookies as we have all the vendors out there to kick them into line. Needless to say the vendors make money, MS makes money and we all bend over and take our Tuesday patches in the OS regardless of how we like it or if they work.
      intrepi@...