304754 - document.write on an about: page changes document URI to non-about page

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Paul Nickerson]

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

Comment 1

[Benjamin Smedberg]

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.

Comment 2

[Daniel Veditz [:dveditz]]

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.

Comment 3

[Daniel Veditz [:dveditz]]

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.

Comment 4

[Daniel Veditz [:dveditz]]

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

Comment 5

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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

Comment 6

[Daniel Veditz [:dveditz]]

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.

Comment 7

[Daniel Veditz [:dveditz]]

Attachment: trunk fix merged to aviary branch

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

Comment 8

[Daniel Veditz [:dveditz]]

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

Comment 9

[Boris Zbarsky [:bzbarsky]]

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 10

[Darin Fisher]

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

sr=darin

Comment 11

[Chase Phillips]

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

Per 1.0.7 triage meeting, plussing patch.

Comment 12

[Daniel Veditz [:dveditz]]

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

Comment 13

[Bob Clary [:bc] (inactive)]

Attachment: testcase

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.

Comment 14

[Mike Schroepfer]

Have we got final verification on this?

Comment 15

[Bob Clary [:bc] (inactive)]

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

Comment 16

[Jesse Ruderman]

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.