More firefox trouble [LWN.net]

May 11, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

A few weeks ago, we covered a set of vulnerabilities in Firefox that were closed with the 1.0.3 release. Once again, Firefox is in the news for security issues -- this time for two security vulnerabilities that, when combined, create a situation that could allow an attacker to install software on a user's machine without any notice to the user.

What is particularly unusual about this disclosure is that it came not from the person who discovered the vulnerability, but from a third party who became privy to discussions about the vulnerability. While one might hope that the ethics of vulnerability disclosure would preclude "outing" a security vulnerability, particularly one discovered by another party, prior to the public release of a fix when it's known the vendor or project is actively working on the issue, the cat is out of the bag now.

The first vulnerability relates to "IFRAME" JavaScript URLs, which can allow an attacker to execute arbitrary code in a user's session. Alone, it could allow malicious sites to steal information from sites previously visited. The second vulnerability is in the "IconURL" parameter in "InstallTrigger.install()", which is not properly verified. This can be exploited to run JavaScript with the escalated privileges of a "Chrome script." The combination of both vulnerabilities can actually allow whitelisted sites, or sites masquerading as a whitelisted site, to take any action of the user, including administrative actions if the user has admin privileges. (This is one of the reasons why users should not make a habit of running as root.)

By default, the Mozilla Update websites were on the Firefox whitelist. The Mozilla Foundation has applied a server-side change to prevent attackers from using those sites. However, users who have added other sites to their whitelist may be at risk on those sites -- though an attacker would need to be able to guess what site a user has whitelisted.

We talked to Chris Hofmann, Mozilla's director of engineering, about the most recent vulnerabilities and Mozilla's security record in general. According to Hofmann, the vulnerability is cross-platform and could potentially affect users of Firefox 1.0.3 on any platform. Hofmann said that the Mozilla Foundation was not aware of any exploits in the wild, and that the premature disclosure of the vulnerability was "a pretty rare exception."

The security researchers and people who are reporting the vulnerability are pretty involved in all steps of the discovery and fixing and reporting process, and that's something different from a commercial company where researchers throw the report over the wall and hope a fix comes back from the vendor. Most of the researchers like the Mozilla system better where they can watch progress and complain if it's not proceeding at the right pace... it's very unusual to see someone report something like this without giving us a shot [to fix the problem first].

We also asked Hofmann if he thought it would be possible to catch all of these vulnerabilities at some point in the future. In short, it looks like the answer is pretty much "no," given the complexity of a Web browser and the nature of the interfaces between components where it is not completely understood how they interact.

At this time, there is not a final Firefox 1.0.4 release, but there are candidate builds available with security fixes and a fix for a DHTML regression in 1.0.3. At a minimum, users should disable software installation until 1.0.4 is available.

(Log in to post comments)

More firefox trouble

Posted May 16, 2005 2:25 UTC (Mon) by apollock (subscriber, #14629) [Link]

I guess what I'm trying to get a handle on is was https://bugzilla.mozilla.org/show_bug.cgi?id=292691 publically accessible after it was first submitted? It doesn't seem to be now.

If so, it's no wonder some nefarious person went "ooh, look a new vulnerability bug report" and made off with it to do all sorts of unpleasant things.

We've seen similar problems with Linux kernel commits as well.

When all development is done in the public eye, you are going to have this problem. I'm not saying public development is a bad thing, but this sort of behaviour is a negative side-effect of it and needs to be handled accordingly.