View All Attachments for Bug 88509

Attachment #41640
mfsa2005-45	text/html	2005-07-12 10:32:49 UTC	1.35 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-45: Content-generated event vulnerabilities</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-45</h1>

<span class="label">Title:</span>      Content-generated event vulnerabilities<br>
<span class="label">Severity:</span>   High<br>
<span class="label">Reporter:</span>   Omar Khan, Jochen, shutdown, Matthew Mastracci<br>
<span class="label">Products:</span>   Firefox, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

In several places the browser UI did not correctly distinguish between true
user events, such as mouse clicks or keystrokes, and synthetic events
genenerated by web content. The problems ranged from minor annoyances like
switching tabs or entering full-screen mode, to a variant on <a
href=mfsa2005-34.html>MFSA 2005-34</a>
<p>
Synthetic events are now prevented from reaching the browser UI entirely
rather than depend on each potentially spoofed function to protect
itself from untrusted events.


<h3>Workaround</h3>

Disable JavaScript.

<h3>References</h3>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=289940">
https://bugzilla.mozilla.org/show_bug.cgi?id=289940</a><br>

</body>
</html>

Attachment #41641
mfsa2005-46	text/html	2005-07-12 10:33:09 UTC	1.52 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-46: XBL scripts ran even when Javascript disabled</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-46</h1>

<span class="label">Title:</span>      XBL scripts ran even when Javascript disabled<br>
<span class="label">Severity:</span>   Low<br>
<span class="label">Reporter:</span>   moz_bug_r_a4<br>
<span class="label">Products:</span>   Firefox, Thunderbird, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Thunderbird 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

Scripts in XBL controls from web content continued to be run even when
Javascript was disabled. By itself this causes no harm, but it could be
combined with most script-based exploits to attack people running
vulnerable versions who thought disabling javascript would protect them.
<p>
In the Thunderbird and Mozilla Suite mail clients Javascript is disabled by
default for protection against denial-of-service attacks and worms; this
vulnerability could be used to bypass that protection.

<h3>Workaround</h3>

Upgrade to a fixed version

<h3>References</h3>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=292591">
https://bugzilla.mozilla.org/show_bug.cgi?id=292591</a><br>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=292589">
https://bugzilla.mozilla.org/show_bug.cgi?id=292589</a><br>

</body>
</html>

Attachment #41642
mfsa2005-47	text/html	2005-07-12 10:33:22 UTC	1.46 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-47: Code execution via "Set as Wallpaper"</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-47</h1>

<span class="label">Title:</span>      Code execution via "Set as Wallpaper"<br>
<span class="label">Severity:</span>   High<br>
<span class="label">Reporter:</span>   Michael Krax<br>
<span class="label">Products:</span>   Firefox 1.0.3<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>

<h3>Description</h3>

If an attacker can convince a victim to use the "Set As Wallpaper" context
menu item on a specially crafted image then they can run arbitary code on the
user's computer. The image "source" must be a javascript: url containing an
eval() statement and such an image would get the "broken image" icon, but with
CSS it could be made transparent and placed on top of a real image.
<p>
This affects only Firefox 1.0.3 and 1.0.4; earlier versions are unaffected.
The implementation of this feature in the Mozilla Suite is also unaffected.


<h3>Workaround</h3>

Disable Javascript, or save the image as a file first and then use the OS's
features to make the image your desktop wallpaper.

<h3>References</h3>

<a href="http://www.mikx.de/firewalling/">http://www.mikx.de/firewalling/</a><br>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=292737">
https://bugzilla.mozilla.org/show_bug.cgi?id=292737</a><br>

</body>
</html>

Attachment #41643
mfsa2005-48	text/html	2005-07-12 10:33:36 UTC	2.63 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-48: Same-origin violation with InstallTrigger callback</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-48</h1>

<span class="label">Title:</span>      Same-origin violation with InstallTrigger callback<br>
<span class="label">Severity:</span>   Low (High for Suite)<br>
<span class="label">Reporter:</span>   Matthew Mastracci<br>
<span class="label">Products:</span>   Firefox, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

The InstallTrigger.install() method for launching an install accepts a
callback function that will be called with the final success or error status.
By forcing a page navigation immediately after calling the install method
this callback function can end up running in the context of the new page
selected by the attacker. This is true even if the user cancels the unwanted
install dialog: cancel is an error status. This callback script can steal
data from the new page such as cookies or passwords, or perform actions on
the user's behalf such as make a purchase if the user is already logged
into the target site.
<p>
In Firefox the default settings allow only http://addons.mozilla.org to
bring up this install dialog. This could only be exploited if users have
added questionable sites to the install whitelist, and if a malicious site
can convince you to install from their site that's a much more powerful
attack vector.
<p>
In the Mozilla Suite the whitelist feature is turned off by default, any site
can prompt the user to install software and exploit this vulnerability.
<p>
The browser has been fixed to clear any pending callback function when switching
to a new site.


<h3>Workaround</h3>

Firefox: Remove untrustworthy sites from the list of those allowed to install,
or turn off software installation entirely.
<ol>
<li>Open the Options dialog from the Tools menu
<li>Select the Web Features icon in the left panel
<li>Uncheck the "Allow web sites to install software" box, or click the
    "allowed sites" button on that line to remove untrusted sites.
</ol>
<p>
Mozilla Suite: Turn off the software installation feature.
<ol>
<li>Open the Preferences dialog from the Edit menu
<li>Select "Software Installation" in the "Advanced" group in
    the left panel.
<li>Uncheck the "Enable software installation" checkbox.
</ol>


<h3>References</h3>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=293331">
https://bugzilla.mozilla.org/show_bug.cgi?id=293331</a><br>

</body>
</html>

Attachment #41644
mfsa2005-49	text/html	2005-07-12 10:33:51 UTC	1.04 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-49: Script injection from Firefox sidebar panel using data:</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-49</h1>

<span class="label">Title:</span>      Script injection from Firefox sidebar panel using data:<br>
<span class="label">Severity:</span>   High<br>
<span class="label">Reporter:</span>   Kohei Yoshino<br>
<span class="label">Products:</span>   Firefox<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>

<h3>Description</h3>

Sites can use the _search target to open links in the Firefox sidebar. A
missing security check allows the sidebar to inject data: urls containing
scripts into any page open in the browser. This could be used to steal
cookies, passwords or other sensitive data.

<h3>Workaround</h3>

Disable Javascript


<h3>References</h3>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=294074">
https://bugzilla.mozilla.org/show_bug.cgi?id=294074</a><br>


</body>
</html>

Attachment #41645
mfsa2005-50	text/html	2005-07-12 10:34:03 UTC	1.36 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-50: Possibly exploitable crash in InstallVersion.compareTo()</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-50</h1>

<span class="label">Title:</span>      Possibly exploitable crash in InstallVersion.compareTo<br>
<span class="label">Severity:</span>   High<br>
<span class="label">Reporter:</span>   shutdown<br>
<span class="label">Products:</span>   Firefox, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

When InstallVersion.compareTo() is passed an object rather than a string
it assumed the object was another InstallVersion without verifying it.
When passed a different kind of object the browser would generally
crash with an access violation.
<p>
shutdown has demonstrated that different javascript objects can be
passed on some OS versions to get control over the instruction pointer.
We assume this could be developed further to run arbitrary machine code
if the attacker can get exploit code loaded at a predictable address.

<h3>Workaround</h3>

Disable Javascript.


<h3>References</h3>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=">
https://bugzilla.mozilla.org/show_bug.cgi?id=</a><br>

</body>
</html>

Attachment #41646
mfsa2005-51	text/html	2005-07-12 10:34:15 UTC	1.13 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-51: The return of frame-injection spoofing</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-51</h1>

<span class="label">Title:</span>      The return of frame-injection spoofing<br>
<span class="label">Severity:</span>   Moderate<br>
<span class="label">Reporter:</span>   Secunia.com<br>
<span class="label">Products:</span>   Firefox 1.0.3, Mozilla Suite 1.7.7<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

The original frame-injection spoofing bug was fixed in the Mozilla Suite 1.7
and Firefox 0.9 releases. This protection was accidentally disabled by one
of the fixes in the Firefox 1.0.3 and Mozilla Suite 1.7.7 releases.


<h3>Workaround</h3>



<h3>References</h3>

<a href="http://secunia.com/advisories/15601/">http://secunia.com/advisories/15601/</a><br>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=296850">
https://bugzilla.mozilla.org/show_bug.cgi?id=296850</a><br>

</body>
</html>

Attachment #41647
mfsa2005-52	text/html	2005-07-12 10:34:30 UTC	1.48 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-52: Same origin violation: frame calling top.focus()</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-52</h1>

<span class="label">Title:</span>      Same origin violation: frame calling top.focus()<br>
<span class="label">Severity:</span>   High<br>
<span class="label">Reporter:</span>   Secunia.com<br>
<span class="label">Products:</span>   Firefox, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

A child frame can call top.focus() even if the framing page comes from a different
origin and has overridden the focus() routine. The call is made in the context
of the child frame. The attacker would look for a target site with a framed
page that makes this call but doesn't verify that its parent comes from the same
site. By framing this page the attacker could steal cookies and passwords, or
take actions on the site on behalf of a signed-in user.


<h3>Workaround</h3>

Disable Javascript. As a website author verify that a parent frame is
from the expected site before calling methods on it.


<h3>References</h3>

<a href="http://secunia.com/advisories/15549/">http://secunia.com/advisories/15549/</a><br>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=296830">
https://bugzilla.mozilla.org/show_bug.cgi?id=296830</a><br>

</body>
</html>

Attachment #41648
mfsa2005-53	text/html	2005-07-12 10:34:44 UTC	2.07 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-53: Standalone applications can run arbitrary code through the browser</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-53</h1>

<span class="label">Title:</span>      Standalone applications can run arbitrary code through the browser<br>
<span class="label">Severity:</span>   Critical<br>
<span class="label">Reporter:</span>   Michael Krax<br>
<span class="label">Products:</span>   Firefox, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

Several media players, for example Flash and QuickTime, support scripted content
with the ability to open URLs in the default browser. The default behavior for
Firefox and the Mozilla Suite was to replace the currently open browser window's
content with the externally opened content. If the external URL was a javascript:
url it would run as if it came from the site that served the previous content, which
could be used to steal sensitive information such as login cookies or passwords.
If the media player content first caused a privileged chrome: url to load then
the subsequent javascript: url could execute arbitrary code.
<p>
External javascript: urls will now run in a blank context regardless of what
content it's replacing, and external apps will no longer be able to load
privileged chrome: urls in a browser window. The -chrome command line option
to load chrome applications is still supported.


<h3>Workaround</h3>

Set the browser to open external links in a new tab or new window.
<ol>
<li>Open the Options dialog from the Tools menu
<li>Select the Advanced icon in the left panel
<li>Open the "Tabbed Browsing" group
<li>Set "Open links from other applications in:" to either new tab or new window
</ol>

Or disable JavaScript.


<h3>References</h3>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=298255">
https://bugzilla.mozilla.org/show_bug.cgi?id=298255</a><br>

</body>
</html>

Attachment #41649
mfsa2005-54	text/html	2005-07-12 10:34:59 UTC	1.54 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-54: Javascript prompt origin spoofing</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-54</h1>

<span class="label">Title:</span>      Javascript prompt origin spoofing<br>
<span class="label">Severity:</span>   Low<br>
<span class="label">Reporter:</span>   Secunia.com<br>
<span class="label">Products:</span>   Firefox, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

Alerts and prompts created by scripts in web pages are presented with the
generic title [JavaScript Application] which sometimes makes it difficult to know
which site created them.  A malicious page could attempt to cause a prompt
to appear in front of a trusted site in an attempt to extract information
such as passwords from the user.
<p>
In the fixed version these prompts will contain the hostname from the
page which created it.

<h3>Workaround</h3>

Do not enter sensitive information into a "JavaScript Application" prompt,
they are almost never used for this purpose. If you must, first drag the
prompt on the desktop and make sure there is not a tiny window hiding
behind it.



<h3>References</h3>

<a href="http://secunia.com/advisories/15489/">https://secunia.com/advisories/15489/</a><br>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=298934">
https://bugzilla.mozilla.org/show_bug.cgi?id=298934</a><br>

</body>
</html>

Attachment #41650
mfsa2005-55	text/html	2005-07-12 10:35:12 UTC	1.42 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-55: XHTML node spoofing</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-55</h1>

<span class="label">Title:</span>      XHTML node spoofing<br>
<span class="label">Severity:</span>   High<br>
<span class="label">Reporter:</span>   moz_bug_r_a4<br>
<span class="label">Products:</span>   Firefox, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

Parts of the browser UI relied too much on DOM node names without taking
different namespaces into account and verifying that the node was really
of the expected type. An XHTML document could be used, for example, to
create fake <IMG> elements with content-defined properties that will
be accessed as if they were the trusted built-in properties of the expected
HTML elements.
<p>
The severity of the vulnerability would depend on what the attacker could
convince the victim to do, but could result in executing user-supplied
script with elevated "chrome" privileges. This could be used to install
malicious software on the victim's machine.


<h3>Workaround</h3>

Disable Javascript.

<h3>References</h3>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=298892">
https://bugzilla.mozilla.org/show_bug.cgi?id=298892</a><br>

</body>
</html>

Attachment #41651
mfsa2005-56	text/html	2005-07-12 10:35:25 UTC	1.41 KB	no flags	Details

<html>
  <head>
    <title>MFSA 2005-56: Code execution through shared function objects</title>
    <style>
       .label { width: 8em; font-weight: bold; float: left;}
    </style>
  </head>
<body>
<h1>Mozilla Foundation Security Advisory 2005-56</h1>

<span class="label">Title:</span>      Code execution through shared function objects<br>
<span class="label">Severity:</span>   Critical<br>
<span class="label">Reporter:</span>   moz_bug_r_a4, shutdown<br>
<span class="label">Products:</span>   Firefox, Mozilla Suite<br>
<br>
<span class="label">Fixed in:</span>   Firefox 1.0.5<br>
<span class="label">&nbsp;</span>      Mozilla Suite 1.7.9<br>

<h3>Description</h3>

Improper cloning of base objects allowed web content scripts to
get to a privileged object by walking up the prototype chain.
This could be used to execute code with enhanced privileges.


<h3>Workaround</h3>

Disable JavaScript

<h3>References</h3>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=294795">
https://bugzilla.mozilla.org/show_bug.cgi?id=294795</a><br>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=294799">
https://bugzilla.mozilla.org/show_bug.cgi?id=294799</a><br>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=295011">
https://bugzilla.mozilla.org/show_bug.cgi?id=295011</a><br>

<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=296397">
https://bugzilla.mozilla.org/show_bug.cgi?id=296397</a><br>

</body>
</html>