858721 - UXSS using carefully timed history navigations

Status: NEW

(Core :: DOM: Navigation, defect)

Description

[Mariusz Mlynski]

It is possible to load an arbitrary website contained in an iframe such that its document's baseURI points to the attacker's location. This allows cross-site scripting when the targeted page loads a script via a relative path.

Comment 1

[Mariusz Mlynski]

Attachment: Exploit

This gets document.cookie for usa.bnpparibas.com. Usage:

1. Upload the exploit to a server that doesn't auto-redirects on file access. This is a fragile piece of code stressing edge conditions, and any unexpected element in the navigation chain will break it (as was the case for previous PoC's running directly from bmo).
2. Upload the /common/ directory to the root of the web server.
3. Run /exploit/index.html. It takes about 15 seconds to complete.

I've tested in Firefox 20 and the latest Nightly.

Comment 2

[Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]]

this seems like an extreme corner case so I am thinking sec-moderate at best, assigning to mgoodwin to verify and look over

Comment 3

[Justin Lebar (not reading bugmail)]

What in particular makes this a corner-case?

Comment 4

[Justin Lebar (not reading bugmail)]

If he's achieving universal XSS, this seems clearly sg-high to me, no matter how fiddly the testcase may be.  That's how we flagged all of the previous bugs that are similar to this one (there have been many).

Comment 5

[Mariusz Mlynski]

Attachment: Exploit - Wikipedia

Granted, a random bank website isn't too impressive as a XSS target. Here's an exploit for Wikipedia. I've made a minor timing fix, so if you experience problems with the previous testcase, try this one out.

Comment 6

[Mariusz Mlynski]

Attachment: Exploit - Wikipedia

I missed that the injected code fails to load when the file being swapped is cached and Wikipedia hasn't been loaded earlier in the browsing session. I'm attaching a (hopefully) final version that works around this issue.

Comment 7

[Bobby Holley (:bholley)]

Is this related to the fact that we get the script entry point wrong in this case? If so, this is probably a more interesting attack using the same underlying bug as bug 810808.

We basically need to implement the script entry point stack properly here.

Comment 8

[Justin Lebar (not reading bugmail)]

I'm not actually convinced that this uses the same bug as 810808.

Cursorily, it looks like the exploit gets around the history-object blocking by doing history.back() on the window he controls, and relying on the fact that that navigates the cross-origin iframe.

Comment 9

[Bobby Holley (:bholley)]

(In reply to Justin Lebar [:jlebar] from comment #8)
> I'm not actually convinced that this uses the same bug as 810808.
> 
> Cursorily, it looks like the exploit gets around the history-object blocking
> by doing history.back() on the window he controls, and relying on the fact
> that that navigates the cross-origin iframe.

Wait, can History.back cause descendant docshells to navigate as well? I thought that whenever we navigated a docshell node all child nodes went away.

Comment 10

[Justin Lebar (not reading bugmail)]

> Wait, can History.back cause descendant docshells to navigate as well?

Yeah, you can test with

> data:text/html,<button onclick="history.back()">Back</button><iframe src="http://wikipedia.org">

Comment 11

[Boris Zbarsky [:bzbarsky]]

history.back() goes one step back in the history.  There is one history per toplevel navigation context (aka tab).  back() anywhere in the navigation context tree will, iirc, navigate whatever frame in that navigation context tree last navigated or something.

Comment 12

[Justin Lebar (not reading bugmail)]

(In reply to Boris Zbarsky (:bz) from comment #11)
> history.back() goes one step back in the history.  There is one history per
> toplevel navigation context (aka tab).  back() anywhere in the navigation
> context tree will, iirc, navigate whatever frame in that navigation context
> tree last navigated or something.

Which means that restricting the history object to same-origin pages does nothing to protect us from attacks, unless we also change how history.back works.  :(

Comment 13

[Bobby Holley (:bholley)]

Yikes. Does our history.back behavior match the spec? I just spent some time reading the session history stuff in the spec, but my eyes glazed over before I got a full picture. I can dig more if nobody knows that part of the spec well, I guess.

Comment 14

[Andrew McCreight [:mccr8]]

Olli, can you maybe take a look at this?  Thanks.

Comment 15

[Mariusz Mlynski]

The exploits stopped working in Nightly 2013-05-16. At a glance, the caching behaviour was changed such that the PoC's no longer navigate to the target site after the final call to history.back(). I think this may be a side effect of the following code revision:

https://hg.mozilla.org/mozilla-central/rev/1695bdfbfa8e

Comment 16

[Olli Pettay [:smaug][[e-mail]]]

Oh, is this a dup of Bug 848253. I'll investigate.

Comment 17

[Andrew McCreight [:mccr8]]

As this looks like a dupe of another fixed bug, and is being left open so Olli can take a look into it, I'm going to mark this sec-audit.