Making open-source browsing safe for the masses

Black Hat It's been an eventful month for Window Snyder. As chief security something or other at Mozilla, Snyder has shepherded two updates that fixed critical vulnerabilities in the way the browser handles uniform resource identifiers.

The most recent patch punctuated several weeks of debate over exactly who owned the vulnerability. Initially, researchers discovered that Internet Explorer, when it visited a malicious website, could cause Firefox to execute the code without first vetting it for security. Microsoft security wonks said the problem resided with Firefox.

Mozilla quickly fixed the vulnerability, but also called on Microsoft to patch IE, arguing that other Windows applications were also at risk of being tricked by IE into running malicious code. Soon after, researchers discovered that Mozilla could also pass along attack code to other programs.

We caught up with Snyder at the Black Hat conference in Las Vegas and asked her to reflect on the lessons learned and to discuss other issues confronting Mozilla's security team.

Q: Has it not been an unusually active month for you and the rest of the Mozilla security team?

A: It's been unusually busy because this is a difficult problem, a difficult set of related problems and the discussion around it demonstrates how complicated the issue is. And of course we get to a certain point and that's actually how we ended up shipping 2.0.0.6. We shipped 2.0.0.5.

The issue we fixed in 2.0.0.5 we were the application accepting bad data, in this case from IE. So we put a patch in to prevent Firefox from accepting bad data and then find out a couple days later that, oh in fact we can also be the entry point.

So it's a related issue but it's a different bug in terms of the software. So we shipped 2006 to escape quotes and reduce the risk of Firefox acting as the entry point for that same scenario. Because there are two applications involved, we started off on one side and found out we could also be on the other side. We didn't realize we could be the entry point as well. So that's why we ended up shipping 2006.

All the discussion around it has to happen. Otherwise we wouldn't have found that issue. All that discussion around it is very productive.

Q: Remind us what was the debate and why was it such a difficult issue for you guys to figure out?

The debate involves whose problem is it because there are two applications involved. It doesn't actually matter whose problem it is because it needs to be fixed at both points. So that's why we shipped 2005 so quickly. We have an issue here, we need to do our part and make sure that we're not accepting bad data. So we get 2005 out and we find out we thought we were not able to be the entry point. We did not think we were able to be the entry point because of a number of different cases for different protocols that made it look like we were not going to be vulnerable to that.

Q: Microsoft's response was that this is not their problem and they have not so far as I know changed that response. What's your reaction to that?

It's a problem on both sides. If the entry point to the system in this case is the web browser and the web browser is passing data potentially to all these other applications it's nice to think that you could ask every application to prevent bad data from being accepted but in reality you need to fix it at the entry point because you can't anticipate that every application is going to be able to fix it or understand every way to prevent it. It's difficult to do it at the entry point, but something needs to happen there.

Q: What else has been going on in the last three to six months that you think is representative of where we're headed right now?

We're doing a lot of work getting Firefox 3 out. We're trying to communicate differently about security. You may have seen from the blog posts. We're experimenting with how to get out as much information to our users as possible to prevent speculation about is this the issue, is this the issue? What should we do about it?

Trying to make sure we're able to give our users as much information as we have. And sometimes that means we're going to get new information following that that changes the story. But as long as it's understood that you're looking at a work in progress, you're looking at the details of engineering, you're looking at details and analysis, you're not necessarily getting the final summary. I think that's more useful until hearing nothing until we have all of the analysis done and a fix in progress or a fix available.

So we're trying to balance giving more information earlier with the fact that it's going to change as we do further analysis and as we're building a fix.

Also for issues that are already public, there's not any more risk to our users if the world can see the discussion that we're going through as we fix it, pointing out where those bugs are so people can follow along if they're interested.