I’ve previously posted about the .NET Framework Assistant add-on that was delivered via Windows Update earlier this year. It’s recently surfaced that it has a serious security vulnerability, and Microsoft is recommending that all users disable the add-on.

Because of the difficulties some users have had entirely removing the add-on, and because of the severity of the risk it represents if not disabled, we contacted Microsoft today to indicate that we were looking to disable the extension and plugin for all users via our blocklisting mechanism. Microsoft agreed with the plan, and we put the blocklist entry live immediately. (Some users are already seeing it disabled, less than an hour after we added it!)

Update (Sunday Oct 18, 6:30pm PDT): Microsoft has now confirmed that the Framework Assistant add-on is not a vector for this attack, and we have removed the entry from the blocklist. We are also working on a mechanism to allow Firefox users to re-enable the WPF plugin ahead of its eventual removal from the blocklist. For more information, see Mike Shaver’s latest blog post.

The URL in the address bar can be spoofed when a new window or tab is opened by a malicious web page.

Impact to users

If a user visits a page hosting this malicious code, a new window or tab can be opened with a faked URL.  There is no way of determining if the URL is authentic.  This could result in the user disclosing confidential information to the malicious site, known as a phishing attack.

Status

This vulnerability is known to affect all current versions of Firefox.  Mozilla is actively working on fixing this vulnerability.  Users can mitigate this vulnerability by only sharing confidential information with websites that were opened from a bookmark, a trusted source, or by manually opening a new tab or window and entering a URL.

Credit

This issue was originally reported by Juan Pablo Lopez Yacubian.

Details

On Windows, Firefox 3.0.x and Firefox 3.5.x are terminated due to an uncaught exception during an attempt to allocate a very large string buffer; this termination is safe and immediate, and does not permit the execution of attacker code.

On the Macintosh in Firefox 3.0.x and 3.5.x, a crash occurs inside the ATSUI system library (part of OS X), due to what appears to be a failure to check allocation results. This issue is likely to affect any application using the recommended text-handling libraries on OS X. We have reported this issue to Apple, but in the event that they do not provide a fix we will look to implement mitigations in Mozilla code. We recommend that other developers who use these libraries consider a similar practice, and we have added mitigations in the past for similar bugs in these libraries.

On Linux, the problem is similar to that on Mac: there is an abort in system libraries (pango, glib, libc). Due to the wide variation of Linux libraries and versions deployed, and different compilation options chosen by Linux distributors for Firefox, the details of the crash report may vary between machines.

As a result of our analysis, we do not believe that this represents an exploitable vulnerability in Firefox. Further, we believe that the IBM report is in error, and that the severity rating in the National Vulnerability Database report is incorrect. We have contacted them and hope to resolve the inaccuracies shortly.

[Updated (July 19, 8:50pm EDT): thanks to Larry Seltzer for bringing to our attention that Firefox 3.5.x will indeed still crash using the provided PoC on Windows, at least for some users.]

[Updated (July 20, 8:50am EDT): the SecurityFocus report has been updated to indicate that it is only a denial of service issue. This is consistent with our analysis; thanks to SecurityFocus for correcting their error.]

[Updated (July 20, 9:15am EDT): added results for Linux, thanks to Kevin Brosnan.]

Mike Shaver
VP Engineering, Mozilla Corporation

A bug discovered last week in Firefox 3.5’s Just-in-time (JIT) JavaScript compiler was disclosed publicly yesterday. It is a critical vulnerability that can be used to execute malicious code.

Impact

The vulnerability can be exploited by an attacker who tricks a victim into viewing a malicious Web page containing the exploit code. The vulnerability can be mitigated by disabling the JIT in the JavaScript engine. To do so:

1. Enter about:config in the browser’s location bar.
2. Type jit in the Filter box at the top of the config editor.
3. Double-click the line containing javascript.options.jit.content setting the value to false.

Note that disabling the JIT will result in decreased JavaScript performance and is only recommended as a temporary security measure.  Once users have been received the security update containing the fix for this issue, they should restore the JIT setting to true by:

1. Enter about:config in the browser’s location bar.
2. Type jit in the Filter box at the top of the config editor.
3. Double-click the line containing javascript.options.jit.content setting the value to true.

Alternatively, users can disable the JIT by running Firefox in Safe Mode.  Windows users can do so by selecting Mozilla Firefox (Safe Mode) from the Mozilla Firefox folder.

Status

Mozilla developers are working on a fix for this issue and a Firefox security update will be sent out as soon as the fix is completed and tested.

Credit

Zbyte reported this issue to Mozilla and Lucas Kruijswijk helped reduce the exploit test case.

Update: This vulnerability has been fixed in Firefox 3.5.1, released Thursday, July 16, 2009

The pwn2own bug that Nils discovered at CanSecWest 2009 and the XSLT vulnerability recently made public by Guido Landi (http://www.securityfocus.com/bid/34235) are both critical issues that can result in malicious code execution.

Impact

These issues can be exploited by tricking a user into visiting a malicious web page hosting the exploit code. The pwn2own bug can be mitigated by disabling JavaScript.

Status

Both issues have been investigated and fixes have been developed which are now undergoing quality assurance testing. These fixes will be included in the upcoming Firefox 3.0.8 release, due to be released by April 1. You can follow our work in bugzilla.

Credit

The pwn2own bug was reported to Mozilla by Nils via the Zero Day Initiative (ZDI). The XSLT issue was discovered on http://www.milw0rm.com/exploits/8285, credited to Guido Landi.

Bit9 says it drew up this list by identifying popular applications that have had a critical vulnerability reported in 2008. This is an ineffective test, as it rewards software companies that conceal their security vulnerabilities. Mozilla focuses a great deal of energy on building world class code, and we stand by our reputation on security; we don’t play games with it.

Mozilla security process involves regularly identifying, fixing, testing, and releasing security updates to keep our users safe, and we do that in a public way so that others can scrutinize our processes and help make them better. To suggest that this openness is a weakness because it means that we have “reported vulnerabilities” is to miss the reality: that software has bugs. A product’s responsiveness to those bugs and its ability to contain them quickly and effectively is a much more meaningful metric than counting them.

Bit9 seems to understand this in its focus on application support for updates, but again it fails to account for the real world experience.  Firefox does not deliver WSUS updates, but our built-in update mechanism requires no user intervention, and we consistently see 90% adoption within six days of a new update being released.

The Firefox vulnerabilities Bit9 discusses are long-since fixed, with the majority of these fixes coming within days of it being announced.  That is the real measure of application security: are known vulnerabilities fixed promptly, tested carefully, and deployed thoroughly? When people have asked that question, Firefox and Mozilla have consistently come out ahead.

Bug counting is unfortunately common because it’s easy, but it should not be a substitute for real security measurement. This is why we’ve continued to work on things like the Mozilla security metrics project, to help people make informed decisions about the security of their software. We invite people who are interested to be a part of that process.

Johnathan Nightingale
Human Shield

A null pointer dereference in the content layout component of Firefox allows an attacker to crash the browser when a user navigates to a malicious page.

Impact

If a user browses to a malicious page that takes advantage of this vulnerability, the browser will crash.  A feature in Firefox called Session Restore will restore the browser session when Firefox is restarted and will likely save user typed content in text areas as well.  This feature is designed to save users’ work in the event of a crash or browser restart.

Status

This issue is currently under investigation.  Mozilla has assigned this bug an initial severity rating of low because of the minimal security risk to users.

Credit

Radware reported this issue to Mozilla.

A vulnerability in the way Firefox handles CSS allows an attacker to take advantage of an integer overflow and execute arbitrary code.  In order for the attack to be successful a user must browse to a malicious site.  The advisory is available here.

Impact

This critical vulnerability was reported to Mozilla before details were available publicly.  By keeping the details of the issue private until the issue was patched, TippingPoint and Mozilla were able to keep the risk to users minimal.

Status

This issue is patched in Firefox 3.0.1 and 2.0.0.16 which are now available.  Users will be prompted to install the update through the automatic update feature.  If you would like to update now, select “Check for Updates” from the Help menu.

Credit

An anonymous reporter found this vulnerability and reported it to TippingPoint.  TippingPoint reported it to Mozilla.

TippingPoint will also keep the details closed to protect Firefox users.  From their blog post:

While Mozilla is working on a fix, we wont be divulging anything else until a patch is available, adhering to our vulnerability disclosure policy.  Once the issue is patched, we’ll be publishing an advisory here. Working with Mozilla on past security issues, we’ve found them to have a good track record and expect a reasonable turnaround on this issue as well.

At Mozilla we appreciate any report of security issues because that is how we make the browser stronger and more secure.  The best way to keep Firefox users safe is to report the issues directly to Mozilla as TippingPoint has chosen to, and to wait to release details until a fix is available.

First of all, there is no virus in the Vietnamese language pack. Vietnamese language pack for Firefox users have not been infected with a virus.  The remnant we detected is a line in an html file that would display ads to users.  This does not infect the user’s machine with the virus.  It is a remnant from a virus that most likely infected the language pack developer’s machine. This code remnant is not present in other language packs.  The entire add-ons site has been scanned for malware and viruses and nothing else has been detected. Disabling the language pack in the add-ons dialog disables the code remnant.

Mozilla scans all add-ons for viruses at upload time, but the nature of most anti-virus software is that it only finds the things it knows how to look for.  When this add-on was uploaded there was no signature in the anti-virus software to detect this virus or its remnants.

There have been 16,667 downloads of the Vietnamese language pack since November 2007. It is hard to identify exactly how many users were impacted, but there are on average about 1000 active users.  While the number of users is small, this is still unacceptable.  We take this issue very seriously.  The most likely impact for users was the display of unwanted ads.

These are the steps we have taken to protect users in the future:

•    The add-ons site was immediately scanned for the presence of viruses and other potential malware, and nothing further has been detected.

•    As a response to this issue and to minimize the potential of something similar happening in the future, Mozilla is now scanning all add-ons whenever the signatures for the anti-virus software are updated.