Firefox locks down the components directory

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.