Package Instance

Security research firm Astabis
reported a vulnerability in Firefox 2 submitted through the iSIGHT Partners
GVP Program by Greg McManus, Primary GVP Researcher. The
reported crash in Mozilla's block reflow code could be used by an attacker
to crash the browser and run arbitrary code on the victim's computer.This vulnerability does not affect Firefox 3.Thunderbird shares the browser engine with Firefox and could
be vulnerable if JavaScript were to be enabled in mail. This is not the
default setting and we strongly discourage users from running JavaScript in
mail.

Mozilla developers identified and fixed several stability bugs in the
browser engine used in Firefox and other Mozilla-based products. Some of
these crashes showed evidence of memory corruption under certain
circumstances and we presume that with enough effort at least some of these
could be exploited to run arbitrary code.Thunderbird shares the browser engine with Firefox and could
be vulnerable if JavaScript were to be enabled in mail. This is not the
default setting and we strongly discourage users from running JavaScript in
mail. Without further investigation we cannot rule out the possibility that
for some of these an attacker might be able to prepare memory for exploitation
through some means other than JavaScript such as large images.

Mozilla community member Geoff reported that URL shortcut
files on Windows (for example, saved IE favorites) could be interpreted as if
they were in the local file context when opened by Firefox, although the
referenced remote content would be downloaded and displayed. Scripts loaded
from the remote site would have access to all local file content in Firefox 2
if they were programmed to look for it.Exploiting this vulnerability would involve first fooling the user into
saving such a shortcut to a malicious site--typically from some other program
since Firefox does not use this format--and then find the saved file on the
desktop and choose to open it with Firefox.In affected pre-release versions of Firefox 3 the vulnerability was
further mitigated by the additional restrictions on file content that prevent
searching the local disk in this manner. Malicious scripts could only read
from files with known names stored in the same folder (or sub-folder) as
the shortcut.

Fixes for security problems in the JavaScript engine described in 

MFSA 2008-15 (CVE-2008-1237) introduced a stability problem, where some
users experienced crashes during JavaScript garbage collection. This is being
fixed primarily to address stability concerns. We have no demonstration that
this particular crash is exploitable but are issuing this advisory because
some crashes of this type have been shown to be exploitable in the past.This regression was introduced in Firefox 2.0.0.13 and does
not affect any shipping version of Thunderbird. Thunderbird 2.0.0.14 contains
the correct fix for MFSA 2008-15, although as noted in that advisory
Thunderbird users would be vulnerable only if they had enabled JavaScript.

Mozilla contributor moz_bug_r_a4 submitted a set of
vulnerabilities which allow scripts from one document to be executed in
the context of a different document.  These vulnerabilities could be
used by an attacker to violate the same-origin policy and perform an XSS
attack against arbitrary sites, potentially stealing or manipulating
the user's private information on the victim site.

Mozilla developer Daniel Glazman demonstrated that
an improperly encoded .properties file in an add-on can result in
uninitialized memory being used.  This could potentially result in
small chunks of data formerly used by other programs being exposed
to the add-on code. If the localized string were made available to
web content by the add-on this might leak sensitive data.

Mozilla developers identified and fixed several stability bugs in the
browser engine used in Firefox and other Mozilla-based products. Some of
these crashes showed evidence of memory corruption under certain
circumstances and we presume that with enough effort at least some of these
could be exploited to run arbitrary code.Thunderbird shares the browser engine with Firefox and could
be vulnerable if JavaScript were to be enabled in mail. This is not the
default setting and we strongly discourage users from running JavaScript in
mail. Without further investigation we cannot rule out the possibility that
for some of these an attacker might be able to prepare memory for exploitation
through some means other than JavaScript such as large images.

Opera Software reported a vulnerability which allows malicious content to force the browser into uploading local files to the remote server. This could be used by an attacker to steal files from known locations on a victim's computer.Firefox 3 is not vulnerable to this attack due to the changed
design of the file upload form element.

Security researcher Billy Rios reported that if Firefox
is not already running, passing it a command-line URI with pipe ("|") symbols
will open multiple tabs. This URI splitting could be used to launch 
chrome: URIs from the command-line, a partial bypass of the fix for
MFSA 2005-53 which was intended to
block external applications from loading such URIs (that vulnerability
remains fixed, however).This vulnerability could also be used by an attacker to pass URIs to
Firefox that would normally be handled by a vector application by appending it
to a URI not handled by the vector application. For example, web browsers
normally handle file: URIs themselves, or block them from web
content altogether, but this flaw enabled attackers to pass them from another
browser into Firefox. In Firefox 2 scripts running from file: URIs can read
data from a user's entire disk, a risk if the attacker could first place a
malicious file in a guessable location on the local disk. Rios demonstrated that
the so-called "Safari Carpet-bombing vulnerability" could be used for this,
as well as another technique that does not rely on that now-fixed Safari
vulnerability.In Firefox 3 scripts running in local files have limited access to
other files, almost entirely mitigating the file: attack.
However, combined with a vulnerability which allows an attacker to inject
script into a chrome document the above issue could be used to run
arbitrary code on a victim's computer. Such a chrome injection vulnerability
was discovered in Firefox 3 by Mozilla developers Ben Turner
and Dan Veditz. In the absence of the attack described
by Billy Rios this injection attack would not run with any special privilege
and would be at best a spoofing vulnerability.

Mozilla security researcher moz_bug_r_a4 reported that
when non-privileged XUL documents include scripts from chrome:
URIs used in the browser it was possible to take advantage of the privilege
level stored in the pre-compiled "fastload" file. This could allow an
attacker to run arbitrary JavaScript code with chrome privileges.Thunderbird users are not at risk when JavaScript is
disabled in mail. This is the default setting and we strongly discourage
users from enabling JavaScript in mail.

Mozilla developer John G. Myers reported a weakness in
the trust model used by Mozilla regarding alternate names on self-signed
certificates (and those with mismatched names) that if accepted could
be used to spoof a secure connection to any other site. This problem was
independently reported by Frank Benkstein and
Nils Toedtmann.In Firefox 2 and earlier Mozilla-based browsers, when a user encounters a
site with a self-signed certificate or one whose name does not exactly match
the name in the certificate an error dialog is presented that allows the user
to reject the certificate, or accept it as valid and access the site.
There was no concept of partial trust, accepting the certificate as valid
marked it as trusted for all information it contained, including alternate
site names. These alternate names could be viewed as part of the certificate
details, but since they were not present on the initial dialog many users
could be fooled into accepting a certificate for a site they didn't care about
(but wanted to see) that also asserted that it was a certificate for your bank
or prominent online shop. Once accepted this certificate could be used to
spoof that site or perform a Man-in-the-Middle attack.The dialog has been changed in Firefox 2.0.0.15 to list the alternate
names and users should not accept certificates that claim an unreasonable
set of alternate names. Certificate handling in Firefox 3 is quite different
and it was not susceptible to this vulnerability. In Firefox 3 there is no
dialog to accept self-signed certificates, and when users do choose to make
an exception to the SSL security model the certificate is only trusted
for that one listed exception, not for any other site.

Security researchers Collin Jackson and
Adam Barth reported a series of vulnerabilities which
allow JavaScript to be injected into the context of signed JARs and
executed under the context of the JAR's signer.  This could allow an
attacker to run JavaScript in a victim's browser with the privileges
of a different website, provided the attacker possesses a JAR signed
by the other website.One variant allowed JavaScript to be injected into documents inside
a signed JAR file.  An additional vulnerability exploited signed JAR files
which use relative URLs to JavaScript files. An attacker could use this
vulnerability to trick the browser into treating an attacker-controlled
JavaScript file as the file the signed JAR intended to reference.

Mozilla security researcher moz_bug_r_a4 reported
that mozIJSSubScriptLoader.LoadScript() only applied XPCNativeWrappers to
scripts loaded from standard chrome: URIs. Add-ons using
this feature to load scripts from other schemes such as file:
or data: (typically dynamically generated scripts) and
chrome: URIs using non-canonical package names (e.g. uppercase) did
not have the protective wrappers applied. If the scripts interact
with web content in any way that content could exploit the unwrapped
scripts to run arbitrary code.Firefox itself does not use this feature in a vulnerable way and
users who have not installed any Add-ons are not at risk. We have,
however, identified popular Add-ons using this feature whose
users are at risk and there are no doubt others.Thunderbird users are not at risk when JavaScript is
disabled in mail. This is the default setting and we strongly discourage
users from enabling JavaScript in mail.