MS13-039/ZDI-13-086: Disclosure with a personal touch

This is going to be more of a look at how the “sausage is made”[1] at Zero Day Initiative (ZDI) rather than a deep dive into the technical details of any given vulnerability, but MS13-039 offers both a look at how we normally handle vulnerabilities, and the unusual way we handled this vulnerability.

 

The bug that was to become MS13-039[2] (Vulnerability in HTTP.sys Could Allow Denial of Service) was reported to ZDI near the end of February of 2013. We don’t often buy Denial-of-Service vulnerabilities[3], but this was a persistent denial of service on webservers that required a hard reboot. The write-up was short and to the point, and the vulnerability breathtakingly simple. It was hard to envision the researcher was wrong on something that straightforward.

 

Now, normally we wait for the researcher to accept our offer before we write the advisory that goes to the vendor. After all, why spend the time on writing[4] an advisory before you know if we will be able to purchase the vulnerability? But in between admittedly gleeful shouts that went something like “It hits!”[5], I set up a kernel debugger, confirmed that we were in a true infinite loop, and then sat down and wrote the advisory. After all, you don’t get bugs like this every day, and I wanted to get the bug to the vendor immediately after purchase[6].

 

A couple of weeks later, we were at CanSecWest to run Pwn2Own. In and amongst everything else, I was told that we had in fact purchased the bug. Normally we would disclose to Microsoft via secure@microsoft.com but this vulnerability received a more personal touch.

 

At CanSecWest we had both the entire ZDI team, and the Microsoft MSRC team. And, well, if we were all in one place, and we had this handy Chamber of Disclosure[7], why not do this one in person? Those reading the footnotes already know that I wanted to walk this advisory in in-person, and here we were all in the same place at the same time. The entire Microsoft team was more than willing to get the report in person, the only problem was we didn’t actually have the bug with us.

 

I went back to my room and rewrote the PoC from memory. Even when you are just recreating someone else’s research, huddling up in a room at a conference to write a PoC is fun.

 

So, down to the Chamber of Disclosure we went, and rather than simply turning in the encrypted reports (which works, but is certainly less satisfying) we were able to gather around the laptop and provide the details to the vendor in person.

While this isn’t the normal flow, I think it does highlight some key parts of the process that are generally applicable. First, the basic flow is the same. A researcher submits a find to ZDI. ZDI evaluates it, and either makes or does not make an offer. If and only if the researcher accepts the offer do we provide the information to the vendor. Had the researcher in this case declined our offer, we would have had to walk away from the bug.

 

And finally, we are all on the same side here. To a person, the Microsoft staff at CanSecWest wanted to get the bug report as fast as possible; it may be embarrassing when someone finds a bug that wasn’t caught before release, but they were eager to sit down and go over the details as fast as we could get the PoC recreated. We may not be able to do this in person often (Pwn2Own being really the only exception), but in my experience, vendor security teams really do want to get bugs reported and fixed as fast as they can.

 

--Dave Weinstein, HP Security Research

 

1 Figuratively speaking of course. For those interested in how actual sausage is made, and speaking personally and not as an official endorsement of HP Security Research or ZDI, I’d recommend starting with Charcuterie: The Craft of Salting, Smoking, and Curing, by Michael Ruhlman and Brian Polcyn.

 

2 Those of a certain age may feel free to imagine a “School House Rock” style rolled up piece of parchment singing “I’m just a vuln, and I’m only a vuln…”

 

3 but when we do…

 

4 If only there were a way to write advisories in IDA. Seriously. Actually, not really seriously, but as a rule we’re all far more comfortable with IDA than with prose. It isn’t really surprising that given a choice between writing advisories or doing research, we tend to choose research. Consider it the security researcher’s version of “you can’t have any desert if you don’t eat dinner”; finish your advisories and then you get to go reverse something.

 

5 Perhaps not exactly in those words, as this is a family friendly blog post.

 

6 I believe my words were something to the effect of “I want to walk this one in in person” (footnote 5 also applies here).

 

7 Thanks to Google, who not only provided us the use of their room, but were willing to leave the room when we both needed it at the same time.

Leave a Comment

We encourage you to share your comments on this post. Comments are moderated and will be reviewed
and posted as promptly as possible during regular business hours

To ensure your comment is published, be sure to follow the Community Guidelines.

Be sure to enter a unique name. You can't reuse a name that's already in use.
Be sure to enter a unique email address. You can't reuse an email address that's already in use.
Type the characters you see in the picture above.Type the words you hear.
Search
About the Author


Follow Us
The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation