Security
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.
Brief items
Linux Implements Support For Trusted Computing, Safer Online Transactions (The Gov Monitor)
The Gov Monitor looks at Trusted Computing (TC) features in openSUSE 11.2. "Technikon led a consortium of 23 research and business partners, including AMD, IBM, HP, Infineon and Novell, in developing open source software and applications for TC environments as part of the EU-funded OpenTC project. The groups implementation of TC support in openSUSE version 11.2 involved building a trusted software stack (TSS) for Linux, developing universal virtualisation layers (including improvements to the Xen hypervisor virtual machine monitor) and creating TC and TPM management software. It constitutes a pioneering implementation of TC technology."
New vulnerabilities
asterisk: cross-site ajax requests
| Package(s): | asterisk | CVE #(s): | CVE-2008-7220 | ||||||||||||||||
| Created: | November 24, 2009 | Updated: | June 4, 2010 | ||||||||||||||||
| Description: | From the CVE entry: Unspecified vulnerability in Prototype JavaScript framework (prototypejs) before 1.6.0.2 allows attackers to make "cross-site ajax requests" via unknown vectors. | ||||||||||||||||||
| Alerts: |
| ||||||||||||||||||
bugzilla: information leak
| Package(s): | bugzilla | CVE #(s): | CVE-2009-3386 | ||||
| Created: | November 24, 2009 | Updated: | November 24, 2009 | ||||
| Description: | From the CVE entry: Template.pm in Bugzilla 3.3.2 through 3.4.3 and 3.5 through 3.5.1 allows remote attackers to discover the alias of a private bug by reading the (1) Depends On or (2) Blocks field of a related bug. | ||||||
| Alerts: |
| ||||||
gforge: cross-site scripting
| Package(s): | gforge | CVE #(s): | CVE-2009-3303 | ||||
| Created: | November 23, 2009 | Updated: | November 24, 2009 | ||||
| Description: | From the Debian advisory: It was discovered that gforge, collaborative development tool, is prone to a cross-site scripting attack via the helpname parameter. | ||||||
| Alerts: |
| ||||||
opera: cross-site scripting
| Package(s): | opera | CVE #(s): | CVE-2009-3265 CVE-2009-3266 | ||||
| Created: | November 24, 2009 | Updated: | November 24, 2009 | ||||
| Description: | Cross-site scripting (XSS) vulnerability in Opera 9 and 10 allows remote attackers to inject arbitrary web script or HTML via a (1) RSS or (2) Atom feed, related to the rendering of the application/rss+xml content type as "scripted content." NOTE: the vendor reportedly considers this behavior a "design feature," not a vulnerability. (CVE-2009-3265)
Opera before 10.01 does not properly restrict HTML in a (1) RSS or (2) Atom feed, which allows remote attackers to conduct cross-site scripting (XSS) attacks, and conduct cross-zone scripting attacks involving the Feed Subscription Page to read feeds or create feed subscriptions, via a crafted feed, related to the rendering of the application/rss+xml content type as "scripted content." (CVE-2009-3266) | ||||||
| Alerts: |
| ||||||
php: multiple vulnerabilities
| Package(s): | php | CVE #(s): | CVE-2009-3557 CVE-2009-3558 CVE-2009-3559 | ||||||||||||||||||||||||
| Created: | November 23, 2009 | Updated: | January 25, 2010 | ||||||||||||||||||||||||
| Description: | From the Mandriva advisory: - Fixed a safe_mode bypass in tempnam() identified by Grzegorz Stachowiak. (CVE-2009-3557, Rasmus) - Fixed a open_basedir bypass in posix_mkfifo() identified by Grzegorz Stachowiak. (CVE-2009-3558, Rasmus) - Fixed bug #50063 (safe_mode_include_dir fails). (CVE-2009-3559, Johannes, christian at elmerot dot se) | ||||||||||||||||||||||||||
| Alerts: |
| ||||||||||||||||||||||||||
php-mail: arbitrary file disclosure
| Package(s): | php-mail | CVE #(s): | |||||
| Created: | November 23, 2009 | Updated: | November 24, 2009 | ||||
| Description: | From the VUPEN advisory: A vulnerability has been identified in Debian, which could be exploited by attackers to bypass security restrictions and gain knowledge of sensitive information. This issue is caused by an error in php-mail. The advisory refers to another related advisory, which has more information: A vulnerability has been identified in PEAR Mail, which could be exploited by attackers to bypass security restrictions and gain knowledge of sensitive information. This issue is caused by an input validation error in the "Mail/sendmail.php" script when passing the "form" parameter as an argument to sendmail, which could be exploited by attackers to inject arbitrary arguments and e.g. disclose or copy the contents of arbitrary files. | ||||||
| Alerts: |
| ||||||
qemu: arbitrary code execution
| Package(s): | qemu | CVE #(s): | CVE-2009-3616 | ||||||||
| Created: | November 24, 2009 | Updated: | February 15, 2010 | ||||||||
| Description: | From the CVE entry: Multiple use-after-free vulnerabilities in vnc.c in the VNC server in QEMU 0.10.6 and earlier might allow guest OS users to execute arbitrary code on the host OS by establishing a connection from a VNC client and then (1) disconnecting during data transfer, (2) sending a message using incorrect integer data types, or (3) using the Fuzzy Screen Mode protocol, related to double free vulnerabilities. | ||||||||||
| Alerts: |
| ||||||||||
snort: denial of service
| Package(s): | snort | CVE #(s): | CVE-2009-3641 | ||||||||
| Created: | November 24, 2009 | Updated: | November 24, 2009 | ||||||||
| Description: | From the CVE entry: Snort before 2.8.5.1, when the -v option is enabled, allows remote attackers to cause a denial of service (application crash) via a crafted IPv6 packet that uses the (1) TCP or (2) ICMP protocol. | ||||||||||
| Alerts: |
| ||||||||||
Page editor: Jake Edge
Next page:
Kernel development>>