User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6 certain about:urls are simply chrome pages with lowered priviledges. about:mozilla is one of these pages which can be opened from script. if javascript changes the content of the page (example: document.write), the url is changed to reflect the location of the actual page. this can be used in conjunction with a cross-site scripting vulnerability to acheive chrome priviledges Reproducible: Always Steps to Reproduce: 1. Create a webpage with the following html: <button onclick="window.open ('about:mozilla','_blank')">about:mozilla</button> <br><a href='javascript:document.write("");alert("Page location is "+location.href);'>drag</a> 2. press the button labeled about:mozilla 3. drag the javascript: link to the address bar of the new window. notice the new address Actual Results: about:mozilla is redirect to it's chrome equivalent and script is executed Expected Results: all about: urls (except about:blank) should throw permission denied when opened through script

We have a list of which about: pages are available from the web, and which are not. I'm pretty sure the real bug here is "javascript changes the content of the page (example: document.write), the url is changed to reflect the location of the actual page". This should not happen, and it indicates that somewhere in DOM land we're getting confused about what the page URI actually is.

By typing in the address bar the javascript was injected from the about:foo page itself. If the javascript were executed from some other page then document.write() would change the URL to the location doing the injecting, which would not be a chrome URL. On the other hand if you could inject script that sets the location to a javascript url then you could trigger this bug. The wyciwyg/document.write url fixup should be preserving the about: url, not rewriting to a new scheme.

Nominating for 1.0.7 -- if we don't fix the split-window issues in this branch release then this potentially could be combined with one of those into an arbitrary execution exploit.

The trunk is not vulnerable, the document URI remains the about: url. I'll start looking for the fix.

bzbarsky and dveditz seem to have found the bug that fixed this on the trunk: bug 269827.

The reason the trunk/1.8 is not vulnerable is that this was fixed in bug 289827 in November 2004. I'll attach a merged patch here, the old one doesn't apply cleanly. It also doesn't fully solve the problem, I still don't get the correct about: URI, but at least I get a non-privileged jar: uri instead of the chrome: uri. Many thanks to bz and his awesome cache of nightly builds for fingering exactly when the trunk got fixed.

As mentioned this doesn't make it work entirely correctly but it does stop the privilege escalation.

Nominating for security bounty despite this being a dupe, obviously we didn't recognize the security implications.

Comment on attachment 195951 [details] [diff] [review] trunk fix merged to aviary branch So the reason we get a jar: URI on branch (but not trunk) is that now the original URI is an about: URI. On trunk, the fix for bug 251368 makes us just leave it at that, while on branch we go and get the current channel URI, which is the jar: URI. I guess this is fine since it fixes the security hole and the cosmetic stuff is fixed on trunk...

Comment on attachment 195951 [details] [diff] [review] trunk fix merged to aviary branch sr=darin

Comment on attachment 195951 [details] [diff] [review] trunk fix merged to aviary branch Per 1.0.7 triage meeting, plussing patch.

Fix checked into the aviary and 1.7 branches. Trunk is already fixed by bug 269827

With 1.0.6/winxp dragging the link to the new window shows the alert and changes the url to chrome://global/content/mozilla.xhtml. With 1.0.7/winxp 20050914 dragging the link to the new window shows the alert and changes the url to jar:resource:///chrome/toolkit.jar!/content/global/mozilla.xhtml. With 1.5b/winxp 20050914 dragging the link to the new window shows the document.write and does not alert.

Have we got final verification on this?

Firefox 1.0.7 20050915 Windows XP and Linux show and alert the jar:resource url. Any Mac users to test this?

javascript: URLs no longer execute right away when dragged to an address bar; see bug 291651. Using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051006 Firefox/1.6a1, I tested this in several ways. I thought I saw alert(Components.classes) succeed once when typing or pasting URLs into the address bar, but now I can't reproduce that, and other than that, WFM.