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.
Index entries for this article | |
---|---|
Security | Firefox |
Security | Web browsers |
GuestArticles | Willis, Nathan |
Posted Nov 26, 2009 5:06 UTC (Thu)
by roelofs (guest, #2599)
[Link] (3 responses)
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
Posted Nov 26, 2009 14:36 UTC (Thu)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Nov 27, 2009 11:33 UTC (Fri)
by bangert (subscriber, #28342)
[Link] (1 responses)
Posted Nov 28, 2009 6:53 UTC (Sat)
by njs (subscriber, #40338)
[Link]
Posted Nov 26, 2009 19:15 UTC (Thu)
by zuki (subscriber, #41808)
[Link]
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):
Once you are done, you're done, so not everything is a security hole.
Posted Nov 29, 2009 22:26 UTC (Sun)
by mlankhorst (subscriber, #52260)
[Link]
JSCtypes is a module that exposes C-compatible external library functions to JavaScript code.
Firefox locks down the components directory
Firefox locks down the components directory
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
code to chrome:/ level, have been present in FF?
Firefox locks down the components directory
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...
it is not a security thing
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"
Firefox locks down the components directory
'updating' that file, so their crappy plugin would still work?