
The best way to thwart bad people is to present zero attack surface whenever possible.


Johnathan Nightingale, Security UI Lead, Mozilla

Reading the changelog I found "Add-on update security has been improved by disallowing add-ons that use an insecure update mechanism". Could you make an example of insecure update mechanism? What update method should add-on developers use?

Window Snyder: Add-ons that are hosted on addons.mozilla.org are served using https. This protects the integrity of the connection and prevents man-in-the-middle attacks that could allow an attacker to insert malicious code into an add-on update. Add-ons that are hosted on other sites should use https, but some use http which does not offer the same protection. In Firefox 3 we now require that all add-on updates require https. Any developer creating add-ons for Firefox should use https for their update services.

Firefox will also now automatically check add-on and plugin versions and will disable older, insecure versions. This helps users make sure they are running the most up-to-date versions of their favorite add-ons and are notified when a newer version is available.

Can you tell us more about Private Browsing?

Johnathan Nightingale: Private Browsing Mode was an idea we talked about early in the Firefox 3 release cycle because we sensed a lot of interest in it from the user community. Nailing down exactly what it means, and how best to implement it, though, is a tricky process since it touches almost every aspect of our code. The result is that it won't be built-in for Firefox 3, but that doesn't mean it isn't available. The "Privacy & Security" section at addons.mozilla.org has a bunch of great addons for controlling your information while browsing, including a couple that are specifically focused on a Private Browsing Mode experience. Check out "Stealther", or "Distrust", and see if they fit the bill. The more feedback and usage these addons get, the better tested and robust they become, the easier it is for us to "uplift" the code into a future version of the browser.

What changed in the password manager?

Window Snyder: Password manager saves your credentials for the websites you visit so that you don't have to remember lots of different passwords and enter them every time you visit a site. These passwords can be protected by selecting a master password which is used to encrypt the stored credentials. In Firefox 3, password manager makes it easier to sort and search saved passwords. It now also asks you if you want a password remembered after a successful login. This enables you to choose to save passwords after you've checked that it is the correct password for the site.

Talking about plugins -- does Firefox 3 include any protection against DNS rebinding?

Johnathan Nightingale: We're working on mitigating DNS rebinding pretty actively right now, but rewriting your network code to assume that DNS replies can change from one second to the next is not a small job, so we're aiming for a future version of Firefox there. There's a lot of complexity required to get things right on this one, and it's not something we can solve purely on the browser side either; it's not enough to just segregate the RFC1918 address space. A lot of the threat stories for DNS rebinding focus on corporate intranet walking, for example, but corporate intranets are very likely to have things like explicit proxies, which takes the ability to do IP-space juggling out of our hands, or at leastmuddies the waters. We've been working with people like Adam Barth, the interview subject in your link, on ways to make sure we get this right.

What is the best way to report security bugs to you? Is the Mozilla Security Bug Bounty Program still open? If a reported bug is general enough to affect other software (for example other browsers), what is your policy?

Johnathan Nightingale: If you think you have found a security bug, the best way to get response, triage, and resolution is to send a note to security@mozilla.org. That address is watched by the people best suited to understanding the problem and how to resolve it, and they will keep you involved in the process. Even when we mark a bug as "security sensitive", the original reporter is always able to follow the progress, so they can see for themselves that we are working the problem.

We'll always work with other vendors to make sure that our security announcements don't put their users at risk, and they tend to be reasonably responsive. We don't ever delay our own fixes but in some cases we will, for instance, hold off on opening up a bug with exploit code until other vendors have a solution in place. A great example of that cooperation was at last year's Black Hat, when we released Jesse Ruderman's javascript fuzzer. It was important to us to get it out there for the community to play with and improve, but we made sure to get the other browsers' OK before bringing it public, since it's pretty devastatingly awesome.