Behind the Scenes at Microsoft`s Secure Windows Initiative

Microsoft’s Secure Windows Initiative unit has emerged from the shadows, promising a new level of transparency, as well as details of software vulnerabilities and security bulletins.

SWI, tasked with maintaining and managing all aspects of Microsoft’s mandatory SDL (Security Development Lifecycle), has launched a new blog that provides customers with technical details on security vulnerabilities, mitigations and workarounds.

eWeek Security Watch Editor Ryan Naraine recently spoke with Jonathan Ness, the lead software security engineer on the SWI Defense team, about how software vulnerabilities are rated, what goes on behind the scenes after a security vulnerability is reported, and the ups and downs of working with third-party researchers.

What’s your background? How did you end up at Microsoft?

During the Christmas holidays in 2002, I read the second edition of [Microsoft Senior Security Program Manager] Michael Howard’s “Writing Secure Code” from cover to cover.

I was working in the military at the time, and, after going line by line over the 600 pages in the book, I decided on a whim to apply to Microsoft to work on [Howard’s] team. I went through the interview loop, and here I am on the SWI team, working at Microsoft because of that book.

What’s your role within SWI?

I work on one of the peer teams—SWI Defense—that focus specifically on creating mitigations and workarounds for vulnerabilities.

We work directly with the MSRC [Microsoft Se­­curity Response Center] and the product teams to reproduce vulnerabilities, create and test temporary workarounds, and help with rating the severity of a security issue.

Resource Library:

We always want to make sure we’re offering the right guidance for customers, whether it’s a workaround before a patch is released or product-specific mitigations in the bulletins.

There are other teams within SWI that we work alongside. SWI React, for example, is a peer team that’s responsible for finding vulnerabilities that may be related to an externally reported issue. They build fuzzers [vulnerability-testing tools] to look for specific issues and handle the code review to make sure we’re not missing anything. They handle things like testing the patch, validating some of the work from the product teams.

What happens when a vulnerability is reported by a third-party, or external, security researcher?

When a bug report comes in, the MSRC guys will look it over and work on making sure we have all information to help us reproduce the issue. They will open a ticket, notify the researcher and pass it on to the SWI React team. If it’s something the MSRC flags as critical, SWI React gets on the ball with the MSRC and the [affected] product team immediately.

The priority is to reproduce the vulnerability, look closely at the surrounding code and understand all potential risks. Once they figure that out, we come in to look for mitigations and workarounds to divert the flow of [attack] code—try to block the vulnerable code from being hit.

We’ll go through the entire response process, which includes working with the product team to build a fuzzer and creating an attack tool to look for additional problems. We want to have a tool by the end of the servicing cycle that could have found [that vulnerability] if it didn’t come in from the outside.

There have been complaints from external researchers that Microsoft puts the onus on them to reproduce/prove the vulnerability.

We try to reproduce every vulnerability that comes in. We really do try. We try to gather all the information, whether it’s just an e-mail notice or if there’s a sample exploit. We will look at the code, build the test tools and try really hard to find what the [researcher] is reporting. If we can’t, our only option is to go back to them and ask them to help us reproduce it.

If possible, we’ll try to set up a machine and ask them to hit us with an attack so we can try to capture it. Our priority is to reproduce it, figure out the problem, then get it fixed.

And once it gets reproduced?

My team’s focus is to understand the vulnerability, find places where an exploit can hit the vulnerable code, then research for mitigations and workarounds to protect against the vulnerability.

In some cases, if it’s an issue that requires a [prepatch] security advisory, we’ll release the mitigations to help customers understand how they can protect themselves until we get an update ready. Then, when the bulletins go out on Patch Tuesday, you’ll find our work in the mitigations section.

During the course of an investigation, we learn things that don’t quite fit into the bulletins, so we decided to start a new blog to talk down to the guts of specific vulnerabilities. We’re using the new blog [blogs.technet.com/swi] to get really technical about the vulnerabilities that we’ve fixed, how the mitigations work and some other workarounds that might not be 100 percent effective but still useful for some customers.

On the new blog, how do you balance the need to share technical information and the risk of giving too much guidance to malicious hackers?

We want to be sure people understand the vulnerabilities and all the mitigation guidance. Sure, hackers can use that same information to understand the bug, too, but you have to remember that we’re only dealing with things that are already patched.

We’ve talked internally about walking this fine line, and if we think something we put on the blog could actually help an attacker, we’ll err on the side of not releasing the information. We’re not going to post information that shows how to exploit a specific vulnerability.

We expect to have our blog entries coincide with [Microsoft’s] Patch Tuesdays to go into more detail on the mitigation portion of the bulletins and help to clarify things that didn’t make it into the bulletin.

The bad guys are already reversing our patches as soon as they’re released. They have that research already. We subscribe to commercial exploit packs, so we know what’s happening and the kind of third-party research that’s being done after the patches are released.

There have been criticisms that Microsoft has been very slow to issue prepatch advisories and workarounds for things that are publicly known by hackers. Is that fair?

The advisories are still about giving customers proper guidance as soon as we have something that’s tested and understood. Some things can be murky in the beginning when a vulnerability is complicated, and we’re moving fast to reproduce it and understand the risk. Some things come together quicker than others, and it can be tricky to figure out the right time to post an advisory.

Microsoft’s own security guru, Michael Howard, has made the argument that buffer-related security vulnerabilities found in Windows Vista should be downgraded because of backup mitigations built into the operating system. Is that something the SWI team would consider?

Michael makes a good argument, but we don’t feel good yet about reducing severity ratings for Vista.
This is how we look at it: If an exploit were to hit the vulnerable code, we’ll assume that a hacker can bypass the mitigations. Sure, [Vista] might catch and terminate the process, but, in reality, it still hits the [vulnerable] code.
That’s how we look at it—if it hits the code, then we’ll rate it accordingly.

Even with Protected Mode IE, there are certain ways to break out of that to launch an exploit. We have to take that into consideration when we’re rating bugs—same for the other mitigations. With ASLR [address space layout randomization], for example, if the exploit only works once in 256 tries, we’ll still rate it as if it could be exploited.
There are times when we’ll reduce the severity for things like Windows Server 2003; where scripting is disabled, we’ll drop that down to moderate on server vulnerabilities. But if the affected code is present and you can hit the vulnerable code with an exploit, we’ll rate as if the exploit would have worked.

If it’s a memory corruption vulnerability, we assume the attacker can control the contents of memory, and we rate the bug accordingly. When we apply a rating, we want to be sure people understand the details and the severity clearly so they can make a proper decision.

According to Microsoft’s definitions, a flaw will be rated “critical” if it could be exploited to allow the propagation of an Internet worm without user action. But your IE bulletins are rated critical even if a user has to click on a Web site to be exploited.

We view clicking on a Web page as an expected user action. In fact, for those browse-and-you’re-owned issues, we call those “zero-click vulnerabilities.” We’ll always consider those as critical, even though the word “wormable” doesn’t really apply.