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

RESOLVED FIXED

Status

()

Core
DOM
--
critical
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Paul Nickerson, Assigned: dveditz)

Tracking

({fixed-aviary1.0.7, fixed1.7.12})

1.7 Branch
x86
Windows XP
fixed-aviary1.0.7, fixed1.7.12
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.7.12 +
blocking-aviary1.0.7 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:fix] dupe of bug 269827)

Attachments

(2 attachments)

(Reporter)

Description

12 years ago
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

Updated

12 years ago
Whiteboard: [sg:fix]
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.
Assignee: nobody → general
Component: General → DOM
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.7 Branch
(Assignee)

Comment 2

12 years ago
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.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b5?
Flags: blocking1.7.12?
Flags: blocking-aviary1.0.7?
Summary: some about: urls are chrome pages in disguise → document.write on an about: page changes document URI to non-about page
(Assignee)

Updated

12 years ago
Flags: blocking1.7.13?
Flags: blocking1.7.13+
Flags: blocking-aviary1.0.8?
Flags: blocking-aviary1.0.8+
(Assignee)

Comment 3

12 years ago
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.
Flags: blocking1.7.12?
Flags: blocking-aviary1.0.7?
(Assignee)

Comment 4

12 years ago
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.
(Assignee)

Comment 6

12 years ago
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.
Whiteboard: [sg:fix] → [sg:fix] dupe of bug 269827
(Assignee)

Updated

12 years ago
Depends on: 269827
(Assignee)

Comment 7

12 years ago
Created attachment 195951 [details] [diff] [review]
trunk fix merged to aviary branch

As mentioned this doesn't make it work entirely correctly but it does stop the
privilege escalation.
Attachment #195951 - Flags: superreview?(darin)
Attachment #195951 - Flags: review?(bzbarsky)
(Assignee)

Comment 8

12 years ago
Nominating for security bounty despite this being a dupe, obviously we didn't
recognize the security implications.
Assignee: general → dveditz
Blocks: 256195
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...
Attachment #195951 - Flags: review?(bzbarsky) → review+

Comment 10

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

sr=darin
Attachment #195951 - Flags: superreview?(darin) → superreview+
(Assignee)

Updated

12 years ago
Attachment #195951 - Flags: approval1.7.12?
Attachment #195951 - Flags: approval-aviary1.0.7?

Comment 11

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

Per 1.0.7 triage meeting, plussing patch.
Attachment #195951 - Flags: approval1.7.12?
Attachment #195951 - Flags: approval1.7.12+
Attachment #195951 - Flags: approval-aviary1.0.7?
Attachment #195951 - Flags: approval-aviary1.0.7+
(Assignee)

Comment 12

12 years ago
Fix checked into the aviary and 1.7 branches. Trunk is already fixed by bug 269827
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Flags: blocking1.8b5?
Flags: blocking1.7.13+
Flags: blocking1.7.12?
Flags: blocking1.7.12+
Flags: blocking-aviary1.0.8+
Flags: blocking-aviary1.0.7?
Flags: blocking-aviary1.0.7+
Keywords: fixed-aviary1.0.7, fixed1.7.12
Resolution: --- → FIXED

Comment 13

12 years ago
Created attachment 196092 [details]
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

12 years ago
Have we got final verification on this?

Comment 15

12 years ago
Firefox 1.0.7 20050915 Windows XP and Linux show and alert the jar:resource url.
Any Mac users to test this?
(Assignee)

Updated

12 years ago
Group: security

Comment 16

12 years ago
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.
You need to log in before you can comment on or make changes to this bug.