88167 - Security: session history actions apply javascript: URLs to current page

Status: VERIFIED FIXED

(Core :: Security, defect, P1)

Description

[Jesse Ruderman]

If you have a javascript: URL in session history right before the current page,
then when you hit the Back button (or select the JS url from the Go menu), that
javascript: URL is run against the current page.

This bug allows any web page to gain chrome privileges using the following steps:
- Open a new window.
- Set the new window to go to javascript:try{bad stuff}catch(e){}; 5;
- Set the new window to go to about: (which runs as chrome)
- Tell the new window to history.back, which it can because Window.history and
History.back are allAccess.

Comment 1

[Jesse Ruderman]

Attachment: demo that gets chrome privs

Comment 2

[Bradley Baetz (:bbaetz)]

The fact that about: is chrome is bug 88087 (which I filed this morning). Even
when that is fixed, you can still exploit this using the file/ftp/gopher xul
viewer (which runs as chrome).

Comment 3

[lchiang]

security type of bug.  Putting on PDT radar for now.

Comment 4

[Mitchell Stoltz (not reading bugmail)]

Yeah, this is bad. I think we can't keep from ever displaying chrome in the
content area (though stop me if you disagree...Bradley?). What we can do is
maybe not pass on the system principal (chrome) as the referring principal when
we run a JS URL from bookmarks or history, but use some neutral principal like
about:blank instead.

Comment 5

[Bradley Baetz (:bbaetz)]

I'm not sure whether we can totally prevent chrome being loaded in the content
area, although we should do so where possible.

Could a valid js url get into the history which does something like modify a
window opened to another site? ie will we block something we shouldn't by
restricting this to about:blank?

Can we compile the js url into a function, which will then have the correct
principal associated with it, or something?

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Attachment: First crack at a fix

Comment 7

[Johnny Stenback (:jst)]

So passing a null owner when loading an URL will result in the principal for
about:blank being used?

If so, sr=jst

Comment 8

[Jesse Ruderman]

It sounds like this patch prevents this bug from being used to get chrome privs 
without fixing the cross-domain security hole.

Mitch and I discussed bookmarklets, and we decided that javascript: urls in 
bookmarks should never get chrome privs but javascript: URLs typed into the 
location bar at chrome urls should get those privs.  Is that the policy 
implemented by the patch?  (I thought that would be fixed in a different bug.)

Comment 9

[Mitchell Stoltz (not reading bugmail)]

No, this patch applies to all javascript: URLs, including from the location bar.
I think I'm going to check this one in for tomorrow's candidate build, and then
we can rethink it. I'm not so worried about violating same-origin with
bookmarklets, becuase it requires a lot of cooperation from the user. This patch
will prevent bookmarklets from getting the system principal. As for history,
maybe all javascript URLs loaded from history should run in their own trust
domain (with a principal of "javascript:<whatever>"), which would essentially
make them not work at all when loaded from history. What other options do we have?

javascript URLs run in the context of the current page regardless. They either
have the principal of the page they're running in, or they have some other
principal, in which case they can't access much of anything, not even alert().
We could try to associate principals with history items and have the calling
principal (where the link actually came from - the attacker's principal) carried
around with he URL, but there's probably no point to that because the script URL
would be no less broken than if it had a principal of "javascript:..."

Thoughts? Johnny?

Comment 10

[Bradley Baetz (:bbaetz)]

Mitch walked me through the patch. It doesn't stop the cross domain problem, but
at least you can't get chrome privs any more. I have a stuffed cvs tree, and
can't actually test this at the moment, but since we want to get this in by
tomorrow, r=bbaetz assuming that you've tested it on stuff like window.open with
js urls and so on.

Comment 11

[Johnny Stenback (:jst)]

Mitchell, I was under the impression that we should *never* end up executing
javascript: URL's from session history, 99% of the javascript: URL's out there
won't work anyway if they're executed in the context of another page so there's
no point in putting them in session history. I think mozilla used to not put
them in session history, but it looks like that might have regressed now since I
do see bookmarklets n' such end up in session history.

sr=jst

Comment 12

[Mitchell Stoltz (not reading bugmail)]

Removing PDT+ because the most serious case has been fixed. We still have a
cross-domain exploit here that needs fixing, but we don't need to hold today's
candidate build for it.

I can very easily make it so that javascript URLs, when loaded form history,
have no access to the page. They would still run, but they wouldn't be able to
do much. That may not be the right approach, because URLS that work from links
will throw security errors when loaded from history, and this will confuse
users. Should we not put them in session history at all? This seems like a good
idea, especially if that's the way it used to be. Johnny, how do we do that?

Comment 13

[Mitchell Stoltz (not reading bugmail)]

Attachment: Better patch (Undoes the patch that was already checked in)

Comment 14

[Johnny Stenback (:jst)]

sr=jst

Comment 15

[Mitchell Stoltz (not reading bugmail)]

Attachment: Slight tweak to patch - do the check in the non-session history case only.

Comment 16

[Jesse Ruderman]

r=jesse

Comment 17

[Mitchell Stoltz (not reading bugmail)]

[PDT+] with lchiang's permission, so this can go into tomorrow's build.

Comment 18

[Mitchell Stoltz (not reading bugmail)]

Fixed, trunk and branch.

Comment 19

[lchiang]

bbaetz: since ckritzer is out, can you verify this if you get to it before
Thursday?  Thanks.

Comment 20

[Bradley Baetz (:bbaetz)]

How did this slip through my mail.... Anyway, verified on linux and windows cvs
trunk, and linux cvs branch.

Also verified with windows 2001070608 trunk
mac 2001070604 branch.

This just leaves mac trunk, and sweetlou is down, so I can't get a build.

Comment 21

[ckritzer (gone)]

Marking VERIFIED FIXED on:
-MacOS91 2001-07-09-03-0.9.2
-LinRH62 2001-07-09-04-0.9.2
-Win98SE 2001-07-09-05-0.9.2

Comment 22

[ckritzer (gone)]

Needs trunk verification...

Comment 23

[ckritzer (gone)]

Marking VERIFIED FIXED on:
-MacOS91 2001-07-13-08-trunk
-LinRH62 2001-07-13-08-trunk
-Win98SE 2001-07-13-07-trunk

Comment 24

[Mitchell Stoltz (not reading bugmail)]

Removing NS_Confidential flag.

Comment 25

[Jesse Ruderman]

Months after we fixed this hole, Andreas Sandblad noticed the same hole in IE. 
Microsoft's response was embarrassing.
http://www.wired.com/news/technology/0,1282,51899,00.html (Apr. 17, 2002)