Closed
Bug 88167
Opened 23 years ago
Closed 23 years ago
Security: session history actions apply javascript: URLs to current page
Categories
(Core :: Security, defect, P1)
Tracking
()
VERIFIED
FIXED
mozilla0.9.3
People
(Reporter: jruderman, Assigned: security-bugs)
Details
(Whiteboard: [PDT+])
Attachments
(4 files)
(deleted),
text/html
|
Details | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•23 years ago
|
||
Comment 2•23 years ago
|
||
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).
security type of bug. Putting on PDT radar for now.
Summary: session history actions apply javascript: URLs to current page → Security: session history actions apply javascript: URLs to current page
Whiteboard: [PDT+]
Assignee | ||
Comment 4•23 years ago
|
||
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.
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.3
Comment 5•23 years ago
|
||
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?
Assignee | ||
Comment 6•23 years ago
|
||
Assignee | ||
Updated•23 years ago
|
Whiteboard: [PDT+] → [PDT+] waiting for r/sr
Assignee | ||
Updated•23 years ago
|
Group: netscapeconfidential?
Comment 7•23 years ago
|
||
So passing a null owner when loading an URL will result in the principal for about:blank being used? If so, sr=jst
Reporter | ||
Comment 8•23 years ago
|
||
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.)
Assignee | ||
Comment 9•23 years ago
|
||
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?
Group: netscapeconfidential?
Comment 10•23 years ago
|
||
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•23 years ago
|
||
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
Assignee | ||
Comment 12•23 years ago
|
||
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?
Keywords: nsBranch
Whiteboard: [PDT+] waiting for r/sr
Assignee | ||
Comment 13•23 years ago
|
||
Comment 14•23 years ago
|
||
sr=jst
Assignee | ||
Comment 15•23 years ago
|
||
Reporter | ||
Comment 16•23 years ago
|
||
r=jesse
Assignee | ||
Comment 17•23 years ago
|
||
[PDT+] with lchiang's permission, so this can go into tomorrow's build.
Whiteboard: [RTM+]
Assignee | ||
Updated•23 years ago
|
Whiteboard: [RTM+] → [PDT+]
Assignee | ||
Comment 18•23 years ago
|
||
Fixed, trunk and branch.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 19•23 years ago
|
||
bbaetz: since ckritzer is out, can you verify this if you get to it before Thursday? Thanks.
Comment 20•23 years ago
|
||
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•23 years ago
|
||
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
Status: RESOLVED → VERIFIED
Comment 23•23 years ago
|
||
Marking VERIFIED FIXED on: -MacOS91 2001-07-13-08-trunk -LinRH62 2001-07-13-08-trunk -Win98SE 2001-07-13-07-trunk
Keywords: vtrunk
Reporter | ||
Comment 25•20 years ago
|
||
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)
Updated•19 years ago
|
Flags: testcase+
Updated•18 years ago
|
Flags: in-testsuite+ → in-testsuite?
You need to log in
before you can comment on or make changes to this bug.
Description
•