Matasano Interviews IE Lead PM Christopher Vaughan

Window Snyder | June 20th, 2006 | Filed Under: Interviews

Christopher Vaughan is a Lead PM on the Internet Explorer team over at Microsoft. We met while working on Windows Server 2003 at the twice daily status meeting. Closing in on the ship date this lively (read loud, volatile, hilarious) status meeting goes to three times daily and once on Saturday. He was the representative for Windows Client. I was the Security representive. We had a lot to talk about.

I asked him to answer some questions the Matasano team came up with because he is a real person in the trenches actually working on IE security (not marketing.)
Hi Christopher, can you describe your background and your role at Microsoft?

Hi Window! I’ve been at Microsoft for 11 years. I’ve been involved in every OS release since Windows 95 and every IE release since IE 2 or 3. I discovered in college that computers were what I wanted to work with and once I started down that path, I never looked back.

At Microsoft, I’m one of several Lead Program Managers on the IE team. My team and I are responsible for handling all of the incoming customer & security requests. I also do a lot of security outreach and enjoy spending time at various security conferences worldwide.

There has been a lot of speculation about the upcoming release of Internet Explorer 7. How is IE 7 going to make things better for security?

Security is our biggest single area of investment in IE7. For all the work we did in the UI and platform, none of that outweighs all the security changes we made. We’ve spent time not only developing security features (like our anti-phishing feature), but also supplementing security deep in the product by cleaning up code (like with cURL). Remember too that IE7 is built from the same code base as Windows Vista which has received a huge amount of scrutiny, so this is going to be the most solid code base of IE we’ve ever produced.

If there were three learning lessons from IE 6 that were used to model security in IE7, what would they be?

The first lesson was that the Internet isn’t an innocent place any more. When IE6 was under development 6 years ago, viruses were inconveniences and true Internet crime wasn’t a concern. We’ve designed our new features, and redesigned old features, with this change in mind. Our IDN support is an example of this – we’ve seen how other browsers have been attacked via IDN and think we have a solution that protects our users.

Second, users need more information to make the right choice. We’ve changed our UI in many ways to make it easier for more users to understand the implications of the decisions they’re making. You saw this first in IE for Windows XP Service Pack 2 when we added the information bar. In IE7 we’ve continued this trend by consolidating security feedback into the Address Bar and by driving features like our High Assurance Certificates. No one should have to be a security expert to understand what’s safe and what’s not.

Our third lesson is that security isn’t just about great features and solid code. You also have to have a solid security response plan. You have to engage with the security community. You have to listen to your users. We’ve worked hard over the development cycle of IE7 to do all these things. From the MSRC to our participation at conferences to our feedback database, we’ve making sure that everyone realizes that IE7 isn’t just a product that gets thrown to the wolves, but one that Microsoft will stand by.

We like metrics. How can we measure the scope of the work that went into IE7 or how much more secure it is than IE6?
An easy way to compare IE7’s security vs IE6 will be to see how we do against security threats a year after IE7 is shipped vs our record with IE6 during that same period of time. Hopefully, the need for security response will be lower, the severity of threats will be lower on average, and our turnaround on fixing the issues will be faster. We’ve already showed that we’re trending in the right direction as a company and with products like Windows Server 2003 SP1 and IE6 for Windows XP Service Pack 2 (compared to earlier versions of IE).

Are there any components of IE7 that are implemented in .NET managed code? If not, are there any plans to start incorporating more managed code into IE?
No, IE7 remains purely native code throughout. I think as we develop future versions of IE you’ll see a larger focus on managed code, most likely to enable great plug-ins of that type for our platform. One thing people shouldn’t expect is that IE8 be re-written in managed code. For a variety of reasons, native code is where we’ll stay for a while.

A common approach to securing complex applications (qmail, postfix, ssh) is the use of privilege seperation. Has there been any investigation or plans for a privilege-separated browser architecture?

We’re already moving in that direction. On Windows Vista, IE runs by default in Protected Mode, which is the marketing name for “IE running with lowest possible privileges.” What this means is that IE (and no app, control, toolbar, etc running in IE’s process) has is very restricted to what it can do. It’s less privileged than the user who’s logged in. If someone tries to hijack IE, they can’t write anywhere on the disk except the cache, which is treated as the Internet Zone so it’s already sandboxed. On top of that, users already will be running as regular users (not administrators!) by default, so even if a malicious site does trick the user into running an app, the user by default doesn’t have the ability to affect any part of the system except for their own user profile & files. We understand the benefit of this kind of improvement and IE7 on Windows Vista is a big step in that direction. Our goal is multiple levels of protection, which all together add up to a more secure experience.

Do you think the browsing model where active content is executed in the user’s browser broken? How is it different from active content in office documents? Can these models be fixed?

Well of course you do have to be careful. It’s our responsibility to help users be safe, but users also want a pleasant user experience. Imagine an extensibility model so severely limited that you can’t save files you download from the Internet, run any application, or save settings. It’s our job to draw a line between those two extremes, and that’s what we’ve been doing for the last few years – refining that line.

I want to point out that every browser has an extensibility model of some sort, and they all have security & usability challenges to overcome.

What happened with that Microsoft Internet Explorer JavaScript Window() Vulnerability that was improperly diagnosed as a Denial of Service (DoS) bug and turned out to be remote code execution? After that experience, does the IE team consider all remotely triggerable memory related crashes as high risk issues?

Our understanding of threats evolves all the time. It’s not unusual for code constructs that today people believe are safe to become tomorrow’s security vulnerability. Remember when heap overruns weren’t considered automatically exploitable? When was the first time you heard of Integer Overflow bugs? Everyone’s understanding of code quality (and flaws) is advancing. It’s unfortunate that we mis-diagnosed that case, but we make it a point to try and never get caught in the same way twice.

Every memory related crash is even more thoroughly investigated now. I’m always blown away by the technical prowess of folks around here – and their persistence. No one around here gives up easily on reported flaws until we’re sure confident in our analysis.

On the subject of browser crashes, have you run IE6/7 against HD Moore’s Hamachi? If so, how did they fare? If not, what tools does the IE team use to test browsers?
We run IE7 against all the tools we can find. We use the ones published publicly as well as our own home-grown tools (the PREFIX filters, part of Visual Studio, being one notable tool we’ve released to the world). How’d they do? Let’s just say that we’re not shipping IE7 as long as those tools find exploitable issues.

Is there a clean delineation of security responsibility between the IE team and the underlying components (e.g. image parsers)?

Well, it’s clear at Microsoft that security is everyone’s job. Customers don’t know, don’t care, and shouldn’t have to worry about how we’re organized internally. The IE team drives almost every vulnerability where IE is the attack vector, even if it’s not our code or product that’s at fault. But everyone steps up when we tap them on the shoulder to help out.

A lot of browser exploits are making use of SkyLined’s heap spraying techniques to populate the heap or control values in uninitialized memory. Are there any plans to further isolate the JavaScript engine such as giving it its own address space or dedicated heap?

There’s lots of interesting work in Windows Vista around address spaces etc. Check out Michael Howard’s recent blog entry on that topic. We do have folks thinking specifically about the JavaScipt engine but offhand I’m not sure what the full extent of their plans are. We’ve already made some good changes in IE7 in the way we run scipts to keep users more secure, and I’m sure this is an area we’ll continue to work on even after IE7 ships.

During the WMF SETABORTPROC vulnerability, a third party patch was distributed. Does this represent a shift in how the industry will manage the “zero day threat”?

I don’t think so. I appreciate that there are people out there working to help users stay safe, but it’s more complicated than that. Folks expect Microsoft to be the people who keep Windows safe, and we’ll continue to do so. I shudder at the thought of the ripple effect of other companies trying to patch Windows. Who supports users if the patch breaks applications? Them? Us? How would a user know whom to call? It’s complicated.

Spyware/malware continues to be a top of mind issue for end users. Where do you think spyware is going and what steps is the IE team taking to counter?

Well in one respect, I don’t really care where spyware & malware is going – I just want it eliminated. Whether it’s key loggers or rootkits or adware, our job is simple: keep unauthorized software off of the users’ machines. We’ve attacked this problem at multiple levels as I’ve described throughout this interview. Our #1 goal was eliminating or reinforcing the seams through which the bad guys try to slip their software. And it’s not just code quality, we’re fighting social engineered attacks as well (with our anti-phishing filter). We really want IE7 to be the best-in-class browser for dealing with those kinds of issues.

You can bet that as we work on the next browser after IE7 we’ll continue to invest in that space as well.

Christopher, we want to thank you for your time. Are there any additional thoughts or things you would like to let our readers know?

Thanks for the Q&A time! If there’s anything I’d say to users, it’s that everyone on the IE team is working hard to make IE7 the best browser for our users. We’re excited to ship and look forward to hearing what folks think about what we’ve done. Thanks a lot!