Closed Bug 293302 Opened 15 years ago Closed 15 years ago

Firefox 1.0.3 Critical Vulnerability

Categories

(Firefox :: Security, defect, critical)

Product:
Firefox
Component:
Security
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
VERIFIED DUPLICATE of bug 292691

People

(Reporter: serri_amir, Assigned: dveditz)

References

(
URL
)

Details

(Whiteboard: workaround: disable "tools/options/web-Features/>Allow web sites to install software")

Attachments

(3 files, 2 obsolete files)

Updated patch to fix scope and echo problems.
10.30 KB, patch
Details | Diff | Splinter Review
Testcase - Just for IconURL
1.21 KB, text/html
Details
Testcase for the cross-site scripting part of the problem
1.47 KB, text/html
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; FREE; .NET CLR 1.1.4322)
Build Identifier: 

Remote compromise : http://www.frsirt.com/exploits/20050507.firefox0day.php

Reproducible: Always

Steps to Reproduce:
Summary: Firefox 1.0.3 Critical Vulnerability → Firefox 1.0.3 Critical Vulnerability
Does this code actually do anything? Are there any actual live exploits? I've
tried getting that code to do something, but haven't succeeded.
This exploit will download and execute a malicious file when the user clicks 
on a link. 

Tested on firefox 1.0.3


Tested where? Can you provide a working testcase? Either by attaching it to this
bug, or providing a link?
Attached file Proof of Concept (obsolete) — 
click and see
Attachment #182909 - Attachment mime type: text/html → text/plain
Attachment #182909 - Attachment mime type: text/plain → text/html
Attachment #182909 - Attachment is obsolete: true
Attached file Testcase 2 (obsolete) —
Attachment #182909 - Attachment description: Proof of Concept (from frsirt.com) → Proof of Concept
Attachment #182909 - Attachment filename: exploit.html
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050506
Firefox/1.0+
Trunk is also vunrable.
Possible workaround:

Turn off: Allow web sites to install software in Options... > Web Features

All current PoC's seem to fail if this is turned off.
Whiteboard: workaround: disable "tools/options/web-Features/>Allow web sites to install software"
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.0.4?
Is this an original 0day, or is it a reworking of bug 292691 ?

/be
Assignee: nobody → dveditz
The submitted patch will be committed -- it is a temporary fix while we define a
better solution.
In the previous patch, InstallTrigger.install() was unnecessarily obfuscated. 
$rndNum is stripped now; this has been committed and should be pushed as soon as
possible to prevent JS errors in UMO.
(In reply to comment #9)
> Is this an original 0day, or is it a reworking of bug 292691 ?
> 
> /be

http://addict3d.org/index.php?page=viewarticle&type=security&ID=3919
claims it's a dupe
Attachment #182911 - Attachment is obsolete: false
Testcase throws a JS error now.
We've been slashdotted.
Summary: Firefox 1.0.3 Critical Vulnerability → InstallTrigger URLs have chrome rights
Summary: InstallTrigger URLs have chrome rights → Firefox 1.0.3 Critical Vulnerability
the exploit does not work actually
(In reply to comment #16)
> the exploit does not work actually

We took some steps on the update.mozilla.org side to mitigate the problem.
Can the exploit be used to create files on Linux that can be made executable
(i.e. set the +x bits)?
I'm not sure what the answer is to your specific question but according to
Whitedust Security @ http://www.whitedust.net/newsview.php?NewsID=450 :

"...it has been confirmed that this exploit does not only affect Microsoft
Windows users but, if the code is adapted, can also affect both MacOS and *nix
operating systems running vulnerable version of Firefox...the code uses built-in
Mozilla JavaScript extensions to create a local file in a very straightforward way."
(In reply to comment #19)
My question relates to the fact that on a Unix platform, filenames do not
determine whether or not a file can be made self-executable - the file's
permission bits are the determining factor. If the exploit code can be adapted
to create executable files and/or create shell scripts that can be executed by a
shell, then this exploit is very serious indeed.

I would like to send an update to Secunia on Bug 293302 - Firefox 1.0.3
Critical Vulnerability.

I saw Chris Thomas's post saying "We took some steps on
the update.mozilla.org side to mitigate the problem."  Can someone explain (here
or in an email to me) what steps were taken?

Am I correct if I say "This vulnerability can not be exploited in the
default configuration of Fx because the Fx team has taken steps to
mitigate the problem at (the default sites) update.mozilla.org and
addons.mozilla.org" ?

(In reply to comment #20)
> (In reply to comment #19)
> If the exploit code can be adapted
> to create executable files and/or create shell scripts that can be executed by a
> shell, then this exploit is very serious indeed.

This exploit can ause arbitrary code to run with chrome privileges. It can
therefore do basically anything Mozilla can do, including create, delete, and
modify files.

(In reply to comment #21)
> Am I correct if I say "This vulnerability can not be exploited in the
> default configuration of Fx because the Fx team has taken steps to
> mitigate the problem at (the default sites) update.mozilla.org and
> addons.mozilla.org" ?

Yes, that is correct.
> (In reply to comment #21)
> > Am I correct if I say "This vulnerability can not be exploited in the
> > default configuration of Fx because the Fx team has taken steps to
> > mitigate the problem at (the default sites) update.mozilla.org and
> > addons.mozilla.org" ?
> 
> Yes, that is correct.
Thanks for the quick reply Gavin.  I've sent the update off to Securnia
suggesting that the threat level should be lowered.

However...WhiteDust Security has added an update to the report at
http://www.whitedust.net/newsview.php?NewsID=450 that says:
"To add to the mass of Firefox security fears surrounding this exploit it now
transpires that the "whitelist" which it had been claimed would protect users
from this exploit is in fact faulty. While it is true that Firefox is only
supposed to download and install things from the whitelist in truth it can
easily be fooled into thinking that another site is mozilla.org. As long as you
have any sites listed in your "whitelist" you are vulnerable to this exploit."

Please tell me it isn't so.
(In reply to comment #15)
> We've been slashdotted.

http://it.slashdot.org/article.pl?sid=05/05/08/135217&tid=154&tid=172

For posterity.
Comment on attachment 182911 [details]
Testcase 2

It only works for 1) sites on your whitelist that 2) have an install function
that is callable.  In our case, morgamic basically made the install() function
be randomly named.  

However, if you can add an onclick for that page to call the chrome install()
function, then we have a bigger problem.
Attachment #182911 - Attachment is obsolete: true
(In reply to comment #25)
> (From update of attachment 182911 [details] [edit])
> It only works for 1) sites on your whitelist that 2) have an install function
> that is callable.  In our case, morgamic basically made the install() function
> be randomly named.  
As it turns out, that's not _entirely_ true - there were still ways to exploit
the browser even with the randomized install.  We've moved Mozilla Update to an
untrusted domain name to prevent the remaining issues.
This bug rapidly makes the news-story on major sites like heise.de 
(http://www.heise.de/newsticker/meldung/59374) and other Mailing-Lists like 
http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2005-05/0143.html

*** Bug 293413 has been marked as a duplicate of this bug. ***
(In reply to comment #23)
> However...WhiteDust Security has added an update to the report at
> http://www.whitedust.net/newsview.php?NewsID=450 that says:
> "To add to the mass of Firefox security fears surrounding this exploit it now
> transpires that the "whitelist" which it had been claimed would protect users
> from this exploit is in fact faulty. While it is true that Firefox is only
> supposed to download and install things from the whitelist in truth it can
> easily be fooled into thinking that another site is mozilla.org. As long as
> you have any sites listed in your "whitelist" you are vulnerable to this
> exploit."
> 
> Please tell me it isn't so.

The alarmist article makes it sound like the whitelist compounds the problem. On
the contrary, it means that two flaws have to be exploited rather than just one.

On the whole, the Whitedust article is pretty inaccurate and they don't really
seem to understand how it works. Their fawning over FrSIRT seems to be misplaced
too as from what I can see, FrSIRT just got the flaw details leaked to them.
Read http://greyhatsecurity.org/firefox.htm for a far better explanation.
So is this a dupe and if so, can the other bug now be opened?
(In reply to comment #30)
> So is this a dupe and if so, can the other bug now be opened?

the FrSIRT's advisory was updated to reflect the workaround "the Mozilla 
Foundation patched (partially) this vulnerability on the server side by adding 
random letters and numbers to the "install()" function, which will prevent the 
public exploit from working"

http://www.frsirt.com/english/advisories/2005/0493



(In reply to comment #31)
> the FrSIRT's advisory was updated to reflect the workaround "the Mozilla 
> Foundation patched (partially) this vulnerability on the server side by adding 
> random letters and numbers to the "install()" function, which will prevent the 
> public exploit from working"

Same happened at BID13544 too; "*Update: The cross-site scripting vulnerability
that the publicly available exploit relied on in the mozilla.org domain has been
fixed. This issue is no longer exploitable through this public attack vector."

http://www.securityfocus.com/bid/13544/discussion/
According to Secunia this is Extremely critical (5/5) now:

http://secunia.com/advisories/15292/


(In reply to comment #30)
> So is this a dupe and if so, can the other bug now be opened?

No. This bug covers the publicly announced vulnerability perfectly well. The
developers are using the other bug to probe for similar vulnerabilities that we
don't wish to reveal until the fix is released in 1.0.4
Depends on: 292691
Flags: blocking1.8b3+
Flags: blocking-aviary1.1?
Flags: blocking-aviary1.1+
Flags: blocking-aviary1.0.4?
Flags: blocking-aviary1.0.4+
> (In reply to comment #16)
> > the exploit does not work actually
> 
> We took some steps on the update.mozilla.org side to mitigate the problem.

Correct me if I'm wrong, but doesn't the privilege escalation part only involve
InstallTrigger's iconURL? Can't we just disable the icon URL parameter on UMO
and keep the rest of the code, so that at least people can still install
extensions without needing to do it manually? Or is the problem bigger than I
imagined?

i.e.,

- function install(aEvent, extName, iconURL) {
+ function install(aEvent, extName) {
  ...
    var params = new Array();
    params[extName] = {
      URL: aEvent.target.href,
-     IconURL: iconURL,
      toString: function () { return this.URL; }
    };
    InstallTrigger.install(params);
(In reply to comment #35)
> Correct me if I'm wrong, but doesn't the privilege escalation part
> only involve InstallTrigger's iconURL? Can't we just disable the
> icon URL parameter on UMO and keep the rest of the code[...]?

The bug can be exploited without any help from the trusted site. One empty page
in a trusted domain is enough for a modified exploit to work. The bug has to be
fixed in Firefox before UMO can be restored. UMO should probably keep
redirecting vulnerable Firefox versions to an untrusted domain indefinitely.
There are also third party domains with a high probability of being whitelisted,
if the user is an avid theme and extension fan.

I would also like to add that turning off software installation is insufficient.
The cross site scripting part of the exploit can still be used to steal cookies
from arbitrary sites if the user does not disable Javascript entirely. Since
cookies are frequently used for autologin purposes, this is a very serious
vulnerability.
(In reply to comment #36)
> (In reply to comment #35)
> > Correct me if I'm wrong, but doesn't the privilege escalation part
> > only involve InstallTrigger's iconURL? Can't we just disable the
> > icon URL parameter on UMO and keep the rest of the code[...]?
> 
> The bug can be exploited without any help from the trusted site. One empty page
> in a trusted domain is enough for a modified exploit to work.

Yes, I've just made a modified version of the exploit which works with
http://www.vatica.va (the Holy See): of course I had to add that site to my
white list, but there's no need of particular code on the target page. 
I'd like to add that having a *small* patch in the form of an extension, as an
alternative to the whole 5MB package, is a critical, necessary move.
(In reply to comment #35)
<snip/>
> Correct me if I'm wrong, but doesn't the privilege escalation part only involve
> InstallTrigger's iconURL? 
<snip/>

There is no (AFAIK) need to remove iconURL completely, and I don't expect it to
be removed, because you only need a check for javascript: url's/code.
Is javascript: the only URL that inherits principals in this way? If so, perhaps
the default should be to disallow javascript: URLs in some core code, and then
make the places where they are allowed explicit.
sorry guys, my FF 1.0.2/Win2K isn't vulnerable as I got this JScript error in
stead :

Error: uncaught exception: Permission denied to get property Window.name

UA = Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.6) Gecko/20050317


and yes, I have "allow websites to install software", JScript and java all
enabled...

Sorry.

VGR

----------------
www.europeanexperts.org
to my frSIRT compatriotes : your exploit doesn't work either :D

Error: unterminated string literal
Source File: javascript:'<noscript>'+eval('if
[snip]\'cursor:default;\'>%C2%A0%C2%A0%C2%A0</'+'a>'
Line: 1, Column: 18
Source Code:
'<noscript>'+eval('if (window.name!=\'stealcookies\')

faut faire les choses bien, les gars ;-)

I don't see anything critical in here, as far as I'm concerned ;-)
(In reply to comment #39)
> Is javascript: the only URL that inherits principals in this way? If so, perhaps
> the default should be to disallow javascript: URLs in some core code, and then
> make the places where they are allowed explicit.

Well, Alex Bishops' post at mozillaZine made it clear that some check were
missing "...From my understanding, the problem is basically a few missing
checks..." 
see also: http://mozillazine.org/talkback.html?article=6582#3

and Michael Krax confirmed today (per e-mail) that the iconURL part is basically
the same as https://bugzilla.mozilla.org/show_bug.cgi?id=290036 

and I hope that someone can confirmed this patch/workaround:
news://news.mozilla.org:119/d5ndd3$hv1@ripley.netscape.com
Well thanks kerl ;-)

It's not the first time I post some stuff on bugzilla, and I read all the
comments before, and I just saw :
- that the bug is supposed to affect "1.0.3 and all previous versions" : I don't
see this statement as true.
- that the bug supposedly affects you as soon as you've "enable javascript" and
"enable sites to download software" : I don't see this as true either.

I tried both "exploit proofs of concept" and all fail...

As for the slight modification (random number etc) done on the mozilla site to
work around the problem, I don't think they account for the two errors I got,
namely "access denied to window.name" and "javascript error string unterminated
at...", do they ? ;-)

That's purely factual.

That's all I had to share with people able to read correctly.

Regards
> As for the slight modification (random number etc) done on the mozilla site to
> work around the problem, I don't think they account for the two errors I got,
> namely "access denied to window.name" and "javascript error string unterminated
> at...", do they ? ;-)

The UMO workaround has changed.  The current fix is a new DNS,
do-not-add.mozilla.org.  The testcases attached here used our install function,
but the InstallTrigger.install() is what is vulnerable.
Can we please have a testcase that works with the current 'fix/workaround' for
u.m.o so that we can do some testing?
All you need to do is add a domain to your white list.
(In reply to comment #46)
> All you need to do is add a domain to your white list.

I have already add do-not-add.mozilla.org and it still doesn't work.
This testcase only tests the IconURL part of the vulnerability. Not the cross
site scripting. The testcase only seems to work when you have venkman open. –
very weird.
Or simpler, type the following in the URL bar when you are showing a page on a
whitelisted site (and *please* do not whitelist bugzilla)

javascript:InstallTrigger.install({'blah':{URL:'http://www.mozilla.org',IconURL:"javascript:eval('alert(Components.stack)')"}});void(0)

If you get an alert showing the context stack that shows you've gotten chrome
privileges.
Status: NEW → ASSIGNED
(In reply to comment #49)
> Or simpler, type the following in the URL bar when you are showing a page on a
> whitelisted site (and *please* do not whitelist bugzilla)
> 
>
javascript:InstallTrigger.install({'blah':{URL:'http://www.mozilla.org',IconURL:"javascript:eval('alert(Components.stack)')"}});void(0)
> 
> If you get an alert showing the context stack that shows you've gotten chrome
> privileges.

Thank you, and thank you Gary :-)

Daniel, will the XPInstall process fail in Mozilla Firefox 1.0.4 when the
security manager detects such a script, and if yes, will there be a browser info
message in this case?
(In reply to comment #49)
> Or simpler, type the following in the URL bar when you are showing a page on a
> whitelisted site (and *please* do not whitelist bugzilla)
> 
>
javascript:InstallTrigger.install({'blah':{URL:'http://www.mozilla.org',IconURL:"javascript:eval('alert(Components.stack)')"}});void(0)
> 
> If you get an alert showing the context stack that shows you've gotten chrome
> privileges.

Using "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050510
Firefox/1.0.4" on a site which is "allowed to install software" and with java
and javascript enabled, pasting the above javascript: line in the URL bar
produces no reaction whatsoever, even after hitting Enter or clicking the Go button.

Does that mean my "aviary nightly" version of Fx is already patched against the
exploit?
> Does that mean my "aviary nightly" version of Fx is already patched against the
exploit?

Yes, a checkin was made "mozilla/xpinstall/src/nsJSInstallTriggerGlobal.cpp" to
fix the IconURL issue.

Help is needed with testing. Please see
http://weblogs.mozillazine.org/asa/archives/008121.html 
This is a simplified (sort of) test case based on ffrc.html by Greyhats
Security et al.

Click on the first "click here". An alert saying "www.mozilla.com..." appears
when you are vulnerable and the javascript: URL is re-evaluated within
www.mozilla.com's context.

The second part of the page demonstrates what happens when you try to load
javascript: URL directly into a non-empty iframe. It fails with "Attempt to
load a javascript: URL from one host in a window displaying content from
another host was blocked by the security manager."

It appears there is a problem in nsJSThunk::EvaluateScript
(dom/src/jsurl/nsJSProtocolHandler.cpp). A direct attack is caught but an
indirect one avoids the same-origin check because "owner" is null ("No owner
from channel, use the current URI to generate a principal", see 
http://lxr.mozilla.org/seamonkey/source/dom/src/jsurl/nsJSProtocolHandler.cpp#236)


Does it make any sense to allow the evaluation when the owner is unknown? It is
inherently unsafe to make such a piece of code "fail-open".
This bug is now closed.
Group: security
CC list accessible: false
Not accessible to reporter
Pavel's comment 53 reveals security bug 290982 for which a patch has already
been applied and will be released with the fixes for this bug (as part of the
work on the private duplicate bug 292691)

*** This bug has been marked as a duplicate of 292691 ***
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
Clearing security flag from announced vulnerabilities fixed in Firefox
1.0.4/Mozilla 1.7.8
Group: security
Shouldn't the 'blocking-aviary1.0.5+' flag be replaced by 'blocking-aviary1.0.4+'?
Flags: blocking-aviary1.0.5+ → blocking-aviary1.0.4+
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.