293302 - Firefox 1.0.3 Critical Vulnerability

Status: VERIFIED DUPLICATE of bug 292691

(Firefox :: Security, defect)

Description

[Alex]

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:

Comment 1

[:Gavin Sharp [email: [e-mail]]]

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.

Comment 2

[Alex]

This exploit will download and execute a malicious file when the user clicks 
on a link. 

Tested on firefox 1.0.3

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Tested where? Can you provide a working testcase? Either by attaching it to this
bug, or providing a link?

Comment 4

[Alex]

Attachment: Proof of Concept

click and see

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Confirmed using the
http://illmob.org/files/0day/firefox-download-and-execute.html test page and 1.0.3.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Attachment: Testcase 2

Comment 7

[Steve England [:stevee]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050506
Firefox/1.0+
Trunk is also vunrable.

Comment 8

[Niels Teusink]

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.

Comment 9

[Brendan Eich [:brendan]]

Is this an original 0day, or is it a reworking of bug 292691 ?

/be

Comment 10

[Michael Morgan [:morgamic]]

Attachment: Updated patch to fix scope and echo problems.

Comment 11

[Michael Morgan [:morgamic]]

The submitted patch will be committed -- it is a temporary fix while we define a
better solution.

Comment 12

[Michael Morgan [:morgamic]]

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.

Comment 13

[Peter van der Woude [:Peter6]]

(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

Comment 14

[alanjstr]

Testcase throws a JS error now.

Comment 15

[alanjstr]

We've been slashdotted.

Comment 16

[Alex]

the exploit does not work actually

Comment 17

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(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.

Comment 18

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Can the exploit be used to create files on Linux that can be made executable
(i.e. set the +x bits)?

Comment 19

[Mike Mason]

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."

Comment 20

[Bradley Chapman (not reading bugmail, still gone but not forever)]

(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.

Comment 21

[Mike Mason]

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" ?

Comment 22

[:Gavin Sharp [email: [e-mail]]]

(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.

Comment 23

[Mike Mason]

> (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.

Comment 24

[Thomas K. (:tom)]

(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 25

[alanjstr]

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.

Comment 26

[Chris Thomas (CTho) [formerly [e-mail] [e-mail]]]

(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.

Comment 27

[Markus Hübner]

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

Comment 28

[Jaime Mitchell (use [e-mail] for email)]

*** Bug 293413 has been marked as a duplicate of this bug. ***

Comment 29

[Alex Bishop]

(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.

Comment 30

[alanjstr]

So is this a dupe and if so, can the other bug now be opened?

Comment 31

[Alex]

(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

Comment 32

[Juha-Matti Laurio]

(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/

Comment 33

[Juha-Matti Laurio]

According to Secunia this is Extremely critical (5/5) now:

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

Comment 34

[Daniel Veditz [:dveditz]]

(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

Comment 35

[nrlz]

> (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);

Comment 36

[Johannes]

(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.

Comment 37

[Giorgio Maone [:ma1]]

(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.

Comment 38

[mv_van_rantwijk]

(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.

Comment 39

[Taral]

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.

Comment 40

[VGR]

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

Comment 41

[VGR]

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 ;-)

Comment 42

[mv_van_rantwijk]

(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$[e-mail]

Comment 43

[VGR]

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

Comment 44

[alanjstr]

> 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.

Comment 45

[mv_van_rantwijk]

Can we please have a testcase that works with the current 'fix/workaround' for
u.m.o so that we can do some testing?

Comment 46

[alanjstr]

All you need to do is add a domain to your white list.

Comment 47

[mv_van_rantwijk]

(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.

Comment 48

[Gary van der Merwe]

Attachment: Testcase - Just for IconURL

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.

Comment 49

[Daniel Veditz [:dveditz]]

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.

Comment 50

[mv_van_rantwijk]

(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?

Comment 51

[Tony Mechelynck [:tonymec]]

(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?

Comment 52

[Gary van der Merwe]

> 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 

Comment 53

[Pavel Kankovsky]

Attachment: Testcase for the cross-site scripting part of the problem

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".

Comment 54

[Daniel Veditz [:dveditz]]

This bug is now closed.

Comment 55

[Daniel Veditz [:dveditz]]

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)

Comment 56

[Daniel Veditz [:dveditz]]

*** This bug has been marked as a duplicate of 292691 ***

Comment 57

[Daniel Veditz [:dveditz]]

Clearing security flag from announced vulnerabilities fixed in Firefox
1.0.4/Mozilla 1.7.8

Comment 58

[Pavel Penaz]

Shouldn't the 'blocking-aviary1.0.5+' flag be replaced by 'blocking-aviary1.0.4+'?