|
|
Subscribe / Log in / New account

Firefox locks down the components directory

November 24, 2009

This article was contributed by Nathan Willis

Mozilla announced an important security change in the upcoming Firefox 3.6 that should prevent dangerous behavior caused by external applications bypassing the normal add-on installation process. Starting with 3.6, extensions, plugins, and third-party applications will no longer be able to install code in Firefox's components directory, where much of the browser's own code is housed and loaded automatically. Installing code into the directory was never an approved method, but because the lockdown is a change, Mozilla is providing add-on developers with technical assistance to transition their code to the approved, XPI-based installation scheme. For end users, the change should not adversely affect browsing, but may improve stability and should make for a more secure Firefox experience.

Mozilla's Johnathan Nightingale (whose actual job title is "Human Shield") announced the change on the Mozilla developer center blog on November 16, noting that Firefox is "built around the idea of extensibility" and that although the ability for third-party programs like add-ons to install code in components has been around for a long time, "there are no special abilities that come from doing things this way, but there are some significant disadvantages".

Code installed into the components directory is invisible to end user tools such as the Add-ons Manager, he said, making it impossible to deactivate, and it does not include the version compatibility information that Firefox uses to deactivate deprecated and incompatible add-ons.

Starting with the current beta release of Firefox 3.6, no code except Firefox's known binary components will be loaded from the directory, by checking the file components.list. The change closes bug 519357, the Bugzilla comment thread of which sheds additional light on the implementation. It is still possible for a third-party installer to put binaries or scripts into the components directory, but Firefox will ignore them.

Mozilla developer Vladimir Vukicevic clarified that most extensions and other add-ons are well-behaved in regard to the components directory. "The majority of the problems are actually with third-party apps, such as virus scanners, network optimizers, and similar. These often attempt to integrate with Firefox by dropping a bare component library (a DLL on windows, or a shared library on Linux) into Firefox's component directory." The situation is essentially a non-issue on Linux, but is "pretty prevalent" on Windows. Going forward, he added, third-party applications can hook into Firefox with the same amount of access by providing an extension.

Exactly which legitimate add-ons have been exploiting the components directory loophole is not publicly documented, but one prominent example given in the Bugzilla bug page is Google Desktop Search, which places three files into the directory. Commenters at Slashdot and other web discussion forums pointed fingers at other commercially-developed extensions from Yahoo, Adobe, Sun, and Skype. The mozdev.org plugin documentation for Linux advises installing several older plugins in the components directory, although this is not the recommended approach, and Vukicevic noted that the instructions generally address only XPCOM Type Library (XPT) files, which do not contain any code.

Security with binary and JavaScript add-ons

Vukicevic provided more detail on the issue at his personal blog. Binary code modules in particular took advantage of the components directory to be loaded on application startup, bypassing the version-checking that approved add-ons undergo. Because "the line between supported/frozen and completely unfrozen internal Gecko interfaces is blurred", third-party binaries can cause serious problems when run with a different version of Firefox than the one they were originally written against. Several add-ons taking advantage of the components directory were written for Firefox 3.0, and have not been updated for 3.5, leading to crashes.

Clearly, having executables loaded automatically at application startup simply because they are located in the components directory is a security hole, particularly when they are beyond the reach of Firefox's add-on management interface — some bug reports, such as 503946, suggest isolated incidents of malware attempting to exploit the situation, although no widespread attacks are known. Another risk raised in the Bugzilla comments, however, is the possibility that the legitimate Firefox components could be corrupted or replaced; preventing that attack would require additional measures, like hashing the component contents, which are not part of the current plan. Restricting the components directory to a list of known files is important enough, though, that Vukicevic said it may be backported to 3.5

Vukicevic also hopes that many developers who have relied on binaries in the past — including through the official add-ons approach — will take advantage of another new feature in Firefox 3.6, JSCtypes. JSCtypes is a module that exposes C-compatible external library functions to JavaScript code. This allows add-on authors to call native operating system APIs without writing their add-on as a binary XPCOM component. By keeping as much of the code as possible in JavaScript, Vukicevic said, the chances of breaking the add-on between Firefox revisions is reduced.

To assist affected application and add-on developers to transition away from using the components directory and to standard installation methods, Mozilla has also written a migration document entitled "Migrating raw components to add-ons." The guide covers basic extension authoring, installers, best practices for automatic extension installation, and an introduction to JSCtypes.

Microsoft came under fire earlier in 2009 when its .Net Framework Assistant add-on was automatically installed by Windows Update and tied to a serious security vulnerability. Mozilla used its rarely-triggered add-ons blocklist to disable .Net Framework Assistant. Although it was a high-profile story at the time, the case is noteworthy not because the offending add-on was guilty of exploiting the components directory — it was not — but because the add-on obeyed the rules. Had .Net Framework Assistant dumped unregistered DLLs into the components directory, Mozilla's blocklist feature wold not have been able to automatically deactivate them. Starting with Firefox 3.6, that speculative scenario is no longer a possibility.


Index entries for this article
SecurityFirefox
SecurityWeb browsers
GuestArticlesWillis, Nathan


to post comments

Firefox locks down the components directory

Posted Nov 26, 2009 5:06 UTC (Thu) by roelofs (guest, #2599) [Link] (3 responses)

JSCtypes is a module that exposes C-compatible external library functions to JavaScript code.

On the face of it, that sounds very scary. Are we sure that it does so only for add-ons, not for embedded JS in web pages? (I don't know enough about JS in general and the specifically required Component.whatever call to be able to judge.)

Greg

Firefox locks down the components directory

Posted Nov 26, 2009 14:36 UTC (Thu) by nix (subscriber, #2304) [Link] (2 responses)

The docs explicitly say that it only works for chrome: I haven't checked
the code to see if this is enforced, but the FF hackers aren't complete
idiots so I suspect it is, since they went so far as to document it.

Firefox locks down the components directory

Posted Nov 27, 2009 11:33 UTC (Fri) by bangert (subscriber, #28342) [Link] (1 responses)

except that, in the past a number of privilege escalation bugs, elevating
code to chrome:/ level, have been present in FF?

Firefox locks down the components directory

Posted Nov 28, 2009 6:53 UTC (Sat) by njs (subscriber, #40338) [Link]

Sure, but IIUC chrome privileges *mean* you can do anything firefox can do, e.g. write to arbitrary files; turning this into a full-blown binary code injection is easy. JSCtypes doesn't sound like it lets you do anything you couldn't do before if you really wanted to and didn't care how much wreckage you left in your wake; it just makes it easier and supported.

it is not a security thing

Posted Nov 26, 2009 19:15 UTC (Thu) by zuki (subscriber, #41808) [Link]

Clearly, having executables loaded automatically at application startup simply because they are located in the components directory is a security hole, particularly when they are beyond the reach of Firefox's add-on management interface...

To me this doesn't seem so clear - if something is able to write files in the directory containing the installed program, it already has taken over this user and it might just as well overwrite the whole program with a "special" version. No need to install extensions.

This does seem to be what Mike Shaver thinks (in bug #519357):
This isn't designed to protect against attacks on Firefox; that is a hard battle to win (though we do the hash check on every update, and pave over if there's a mismatch). This is to close off an extension mechanism that "happened to work"

Once you are done, you're done, so not everything is a security hole.

Firefox locks down the components directory

Posted Nov 29, 2009 22:26 UTC (Sun) by mlankhorst (subscriber, #52260) [Link]

Considering it checks the file components.list what would stop anyone from
'updating' that file, so their crappy plugin would still work?


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