They discussed the protection against phishing and the new malware protection, the new update mechanism for add-ons, Mozilla's security policies and processes, and the hardening of their Javascript implementation.

SecurityFocus: Could you introduce yourself?

Window Snyder: I'm the Chief Security Something-or-Other for Mozilla. I work on security strategy, engineering, and communications.

Johnathan Nightingale: My business cards say "Human Shield" but if they were more boring they'd say, "Security User Interface (UI) Lead." My job is to design and implement parts of the browser front-end that help users know who they're dealing with online, and whether their interactions are safe ones. I also represent Mozilla in standards groups on topics of security and usability. As long as I'm annoying an equal number of usability people and security people, I figure I'm doing my job.

Does Firefox 3.0 include any protection against phishing?

Window Snyder: Anti-phishing protection was introduced in Firefox 2.0. It has been very successful in helping users recognize when they've been lured to a site that is masquerading as a well-known legitimate site. To build upon this we've created an interface that enables users to get more information about the site they are visiting by clicking on the favicon in the location bar. This also includes a mechanism to identify Extended Validation Certificates or EV Certs. These certificates are issued to entities after a much more robust identification process than a regular cert. When you visit a site that presents an EV Cert Firefox will display that information in the one-click favicon to make it easier to identify the site you're visiting.

In Firefox 3 we've also added malware protection to prevent users from visiting sites that contain malicious software. If a user stumbles accross a site that has been identified as a site that contains malware, Firefox will prevent the page from loading, and display a page that informs the user that malware has been detected. To further protect users, there's no easy way for the user to accidentally click through the warning.

How does Firefox 3 recognize a "web site that is known to install malware" or a "page that's suspected of being a forgery"?

Johnathan Nightingale: For Firefox 3, we have an agreement in place with Google to use their phishing and malware databases. We pull updates to a local DB about every 30 minutes, and use that to check the sites a user visits before loading. Because we can do that lookup quickly and locally before even connecting to the site we can block the load up front, which is pretty massively preferable to just popping a warning up over the loaded page content. This way even attacks which exploit a flaw in low-level things like the network stack don't get a chance to work, you remain protected. After all, the best way to thwart bad people is to present zero attack surface whenever possible.

How does anti-virus integration work?

Window Snyder: Firefox enables anti-virus tools to work in concert with the browser to check executable as they are downloaded for potential viruses or malware. When a user initiates a download, Firefox informs the anti-virus software so it can check the executable before it can harm the user's machine.

I am a bit puzzled by this new feature: "Web-based protocol handlers. Web applications, such as your favorite web mail provider, can now be used instead of desktop applications for handling mailto: links from other sites. Similar support is provided for other protocols as well. (Note that web applications do have to register themselves with Firefox before this will work.)". How does this registration process between Firefox and "web applications" work?

Johnathan Nightingale: As you mention, web-based protocol handlers basically let you say things like "I use a webmail provider, so when I click on mailto: links, go there, instead of opening my mail client" which we think is pretty handy. The registration API is very simple, the site just needs to tell us:

• What protocol do you want to handle?
• What URL should that redirect to?
• What do you call yourself?

We do, however, have safeguards in place to prevent bad behavior. The user has to consent to this registration in the first place, and a site can't register a handler that lives on a different domain (so, for example, a vulnerability that let people inject JS into a hotmail message couldn't masquerade as hotmail but actually send mailto: requests elsewhere). Registrations are non-exclusive, so registering your new handler isn't going to bump out my previous handler, except of course that you don't get to register for protocols that we handle ourselves, like http.

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.

And yes, the bug bounty program is still active.

What methods did you use to hunt bugs?

Johnathan Nightingale: It would be foolhardy for us to use a single approach (attackers are not so well-behaved) so we tend to pick up any methodology with promise and see what it can do for us. Window has been a great driver here, introducing more targeted penetration testing and more through in-house security reviews as well. We have found fuzzing to be extremely valuable for finding certain kinds of bugs and have developed several tools of our own, including jsfunfuzz which I mentioned earlier. Static analysis tools have been more hit and miss for us but I have the sense that the value of these tools will vary a great deal from one project to the next. In our case, a lot of patterns were flagged as potential problems which turned out to be non-issues after case-by-case inspection.

One of the most valuable tools we have is our manual and automated testing frameworks. We run 55,000 automated tests in 6 different frameworks on 4 platforms at least 20 times a day. Obviously this is a huge deal in terms of avoiding feature regressions, but it also protects against security regressions and it feels now like it would be impossible to do without. The great thing about automated tests in particular is that they are purely additive -- other than negligible time cost for test runs, the incremental cost for adding another test is just the time to write it once, but the protection it offers lasts forever. We've had single tests catch half a dozen regressions in totally unrelated pieces of code.< /p>

Have you included any particular restriction or security check in Firefox 3.0 Javascript implementation?

Johnathan Nightingale: Obviously we tread carefully when we are changing the way the browser permits web pages to behave, since there is a lot of web out there, and we don't want to break it. Nevertheless we have made some small, but smart, changes to the way certain things work. We no longer execute unclosed <script> tags, for instance, because doing otherwise allows a DoS attack to trigger unexpected and potentially dangerous behavior by interrupting pages when scripts are partially loaded. We've also tightened the same origin policy rules around local files so that they can't walk directory trees and send arbitrary content to bad people in shady places.

One of the more exciting changes though, is something that we're still working on, and something where we'd welcome your readers' input. Brandon Sterne, building on earlier work by Gervase Markham, is working on defining a "Site Security Policy" proposal to control things like cross-origin script loading on an opt-in basis. Giving web sites the ability to state explicitly which cross-site traffic is expected and permitted, and which to exclude as rogue would be a big step forward in the battle against XSS and CSRF attacks. It's still in the early stages and obviously in the long term we'd want to get other browsers into the process, but in the meantime, I would encourage your readers to check it out.