LWN.net Logo

Firefox security status

A major security flaw in various third-party extensions has given Firefox a bit of a black eye even though the browser is not vulnerable. A number of other issues in the browser itself caused a security release which kept Firefox in the news. Unfortunately, after the release, even more vulnerabilities were reported. One would have to guess that it has not been the best week or so for the Firefox security team.

A large number of extensions - including toolbars for Google, Yahoo, Facebook and others - are susceptible to a man-in-the-middle attack that allows arbitrary code execution within the browser. The vulnerability exploits the update mechanism built into the extensions by providing malicious code as an update. An attacker that can control the DNS answers received by a victim can redirect the update queries from the extensions to a server under the attacker's control. The code provided gets installed, silently in many cases; it will then run as part of the browser with all of the capabilities of an extension.

Situations where one may not be able to trust the DNS answers received are far more common than people realize. Using a public or unencrypted wireless network is probably the most common vulnerable situation, but home routers that have been subverted either through a vulnerability or because the owner never changed the default password can also leave an opening for an attack. Because the extensions typically check for updates frequently, there are lots of opportunities to provide them with bad code.

There are any number of nasty things that a browser extension can do: keystroke logging, email reading, spamming, bank transfers, subscribing to LWN.net, etc. This is truly a situation that one wants to avoid. Vendors of these extensions have in many cases (with Google being specifically called out in the vulnerability announcement) bypassed the default Firefox prompt that would at least alert users that new code was being installed. Users running those extensions have no defense and need to delete them from the browser while awaiting a fix from the vendor.

The open source extensions that are available at https://addons.mozilla.org are not vulnerable because of the use of SSL to prevent an attacker's host masquerading as the update server. The SSL certificate presented by the attacker's server will not pass muster with the browser so the malicious update will not be installed. This is the fix that the vulnerable extensions will have to implement. It is not particularly technically difficult, more of a logistics headache to roll out new code to millions of users. It may also require some infrastructure improvements to be able to support encrypted connections for that many users.

Millions of users at risk for all manner of browser mayhem may make the fixes in the most recent security update pale by comparison but there are some serious issues there as well. The most important fix, rated as critical by Mozilla, fixes potentially exploitable crashes in the layout and Javascript engines. There is also a flaw that allows cross-site scripting using the addEventListener Javascript call which Mozilla rates as having a high impact.

A few days after the release, Michal Zalewski was up to his usual tricks by reporting two vulnerabilities in Firefox, one that he rates as a major vulnerability, the other as medium. In both cases, various Javascript tricks can be used to make the browser behave badly which is yet another reason to look into the NoScript extension.

Thor Larholm also had some bad news for the Firefox team shortly after the release when he reported that a patch that went into the 2.0.0.4 release only partially fixed the problem for Windows platforms while doing nothing to prevent the problem for Linux and other UNIX versions. The directory traversal vulnerability allows any local files accessible to the browser user with the name known by the attacker to be read via the resource:// URL handler. The information in the file could then be transmitted to any site visited. We can probably expect an update from the Firefox team for this particular problem relatively soon.


(Log in to post comments)

Firefox security status

Posted Jun 7, 2007 4:18 UTC (Thu) by cventers (guest, #31465) [Link]

If SSL scalability is an issue, they should just sign the updates.

Firefox security status

Posted Jun 7, 2007 10:59 UTC (Thu) by ekj (guest, #1524) [Link]

The Mozilla-mechanism is unsane though. Requiring updates to be served from SSL-sites has numerous drawbacks, for example it requires you to have a server on a separate IP-adress, which costs extra for many using shared hosting. And it requires you to purchase an SSL-certificate, which is also extra hassle for no benefit whatsoever.

There exists a well-tested, secure, easily implementable, no-server-impact solution for installing updates, while being certain that they come from who they claim to come from. It's called a digital signature. Package-managers have had them for years.

Sign packages, ask on first installation of a module if you also want the issuer for providing updates, if yes, auto-install updates, but only if they have a good signature from the same developer.

This also allows you to get the updates packages from anywhere, so it allows mirroring of plugin-update-sites without sacrificing security, something that is NOT possible with the "use only HTTPS" solution.

Firefox security status

Posted Jun 7, 2007 11:43 UTC (Thu) by hawk (subscriber, #3195) [Link]

The problem that is "solved" with a certificate handed out from a trusted authority is obviously proving who the software came from in the first place. (So I wouldn't say that the hassle of buying a certificate is for no benefit!)

I do however agree that having this security on the HTTP layer is not really the right choice. On the other hand, having the extensions signed with a certificate handed out by a trusted party seems like a good idea to me.

What you describe (as your description does not seem to involve getting such a certificate) will only be able to tell whether updates come from the same source that you got the initial version from, which still leaves a big whole.

On the other hand, how do you know who to trust in the first place anyway....

Firefox security status

Posted Jun 8, 2007 21:54 UTC (Fri) by ekj (guest, #1524) [Link]

Sure, a certificate signed by one of the CAs that say Firefox trusts by default indicates *something*. Nothing that is useful for deciding if you trust software delivered from that host though.

A Verisign-signed certificate for "foobar.org" shows that Verisign is convinced that the person who they at one time sent the certificate too is the same entity that owns foobar.org.

This helps very nearly not at all.

  • It doesn't tell you what policy foobar.org has for letting people host stuff on their https-server.
  • It doesn't tell you if foobar.org has been compromised and the files trojaned.
  • It doesn't tell you if the developers/owners/administrators of foobar.org are dependable or not.

Firefox security status

Posted Jun 7, 2007 15:48 UTC (Thu) by erwbgy (subscriber, #4104) [Link]

Requiring updates to be served from SSL-sites has numerous drawbacks, for example it requires you to have a server on a separate IP-adress, which costs extra for many using shared hosting.

I agree that signing updates is a better approach, but it is not necessary to have a separate IP to run both an SSL and non-SSL web server on the same host, since they can (and usually do) use different ports - 80 for HTTP and 443 for HTTPS by default. Using Apache IP-based virtual hosts you can even have both in the same instance.

Firefox security status

Posted Jun 7, 2007 18:18 UTC (Thu) by Thalience (subscriber, #4217) [Link]

The issue is that each IP address can host only one SSL site. IP(v4) addresses are a scarce resource, and hosting providers naturally pass the costs associated with this along to their customers.

Not that this is an issue for Google, of course.

Firefox security status

Posted Jun 7, 2007 19:49 UTC (Thu) by Los__D (subscriber, #15263) [Link]

Not true anymore.

The problem originally was that the certificate needs to be served before the headers can be decoded.

If you use the same certificate for all sites (now possible by having them all mentioned in the certificate using subjectAltName), there's no problem.

Firefox security status

Posted Jun 8, 2007 18:11 UTC (Fri) by jengelh (subscriber, #33263) [Link]

Do it the Sourceforge way. One certificate for "sourceforge.net"/www.sourceforge.net, and one for "*.sourceforge.net" that works for all the user projects.

Firefox security status

Posted Jun 8, 2007 21:19 UTC (Fri) by Los__D (subscriber, #15263) [Link]

I can't see how that would work with one IP/virtual hosts?

Before knowing which certificate to show, it'll need to know the hostname, before it can get to the hostname, it needs to decrypt, before it can decrypt, it needs to show a certificate, before knowing which certificate to show, it... And so on, and so forth...

Firefox security status

Posted Jun 8, 2007 21:32 UTC (Fri) by jengelh (subscriber, #33263) [Link]

The ten or so web servers that serve the projects' pages (http://yourproject.sf.net/) all serve exactly one certificate, which certifies "*.sourceforge.net" (yes, this literal string with an asterisk, w/o quotes). Most browsers support this wildcard.
(Minus the fact that project pages are not reachable over https right now...)

Firefox security status

Posted Jun 8, 2007 21:40 UTC (Fri) by Los__D (subscriber, #15263) [Link]

Of course, but you'd still need a seperate IP for the www.sf.net cert(and another for www.sourceforge.net and *.sourceforge.net), if you didn't use subjectAltName

Firefox security status

Posted Jun 8, 2007 21:56 UTC (Fri) by jengelh (subscriber, #33263) [Link]

I never claimed projects.sf.net is the same as www.sf.net. You would have found out by running /usr/bin/host anyway.

Firefox security status

Posted Jun 8, 2007 22:02 UTC (Fri) by Los__D (subscriber, #15263) [Link]

We were discussing if one will need more than one IP for several hosts, I thought that your www.sf.net/*.sf.net suggestion was about using one IP, also for www.sf.net.

I was obviously mistaken.

Firefox security status

Posted Jun 7, 2007 11:21 UTC (Thu) by modernjazz (guest, #4185) [Link]

There are any number of nasty things that a browser extension can do:...
subscribing to LWN.net.

LOL!

...subscribing to LWN.net...

Posted Jun 7, 2007 14:15 UTC (Thu) by dwheeler (guest, #1216) [Link]

This is one of the many things that makes LWN.net special: intelligent, in-depth analysis, combined with wit and humility. Thanks for making my day!

Firefox security status

Posted Jun 11, 2007 18:42 UTC (Mon) by hingo (guest, #14792) [Link]

Me too :-) This one took me off-guard, I was unprepared for another piece Corbet-humor at that point in the article. Thanks for the laughs!!

Firefox security status

Posted Jun 11, 2007 18:51 UTC (Mon) by corbet (editor, #1) [Link]

...except that said article was written by Jake Edge, and not by me at all. Yes, I know, we should make internal authorship more evident...on the list...

File disclosure

Posted Jun 7, 2007 19:41 UTC (Thu) by rise (guest, #5045) [Link]

Private keys for ssh and gpg come to mind as files with known names that a targeted attack might want to grab.

Firefox security status

Posted Jun 10, 2007 13:25 UTC (Sun) by cortana (subscriber, #24596) [Link]

Does anyone know the CVE numbers for Zalewski and Larhom's vulnerabilities?

Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds