300830 - new XUL error page (about:neterror) can load privileged about: urls

Status: RESOLVED FIXED

(Core :: Security, defect)

Description

[shutdown]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b3) Gecko/20050714 Firefox/1.0+ (2005071411)

Since bug 292624 is fixed, XUL error pages no longer have chrome privileges.
However, a new XUL error page (about:neterror) can load other privileged
about: urls. XSS exploits can load XUL error pages first, and then
load about:config to abuse its privileges.

Reproducible: Always

Steps to Reproduce:
1. load XUL error page.
2. input following url into the location bar:
javascript: location = "about:config"; void 0;
3. press enter key or Go button.

Actual Results:  
about:config can be loaded.


Expected Results:  
Security Error: Content at about:neterror?... may not load or link to about:config.

Comment 1

[Benjamin Smedberg]

Is this something that is worth worrying about? What codepath would first be
able to load an error page and then use XSS to load about:config and then use
XSS to do a real attack?

Where is/are the codepath(s) that protect against this for about:blank?

Comment 2

[Jesse Ruderman]

I think the reporter is imagining an attack like this:

1. Malicious web page causes an error page to be loaded.
2. XSS injects script into the error page (using any sufficient XSS hole).
3. Error page loads about:config (using this bug).
4. XSS injects script into about:config (using any sufficient XSS hole).
5. Script in about:config does something bad.

Since this bug turns many XSS holes in Firefox into full compromises, it should
be fixed.

Comment 3

[shutdown]

Attachment: exploit testcase

testcase to demonstrate the problem.
currently, about:neterror is only in the tinderbox builds.

Comment 4

[Daniel Veditz [:dveditz]]

(In reply to comment #3)
> testcase to demonstrate the problem.
> currently, about:neterror is only in the tinderbox builds.

This feature is part of the Deer Park Alpha 2 release.

Comment 5

[Benjamin Smedberg]

I don't know anything about this problem, I'm not a good assignee for this bug.
How do we prevent (for example) about:blank from linking to about:config?

Jesse, I don't see why this should block 1.0.6 since error pages are not on by
default on the branch, and about:neterror doesn't exist.

Comment 6

[shutdown]

(In reply to comment #5)
> I don't know anything about this problem, I'm not a good assignee for this bug.
> How do we prevent (for example) about:blank from linking to about:config?

http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#1161
http://lxr.mozilla.org/seamonkey/source/caps/src/nsScriptSecurityManager.cpp#1257
Non-privileged about: urls are distinguished from privileged ones.

Comment 7

[Daniel Veditz [:dveditz]]

We've got the original problem on the branch still, not this one (although
they're close to the same). On that one we decided that xul error pages weren't
supported on the branch so the fix wasn't needed.

Comment 8

[Daniel Veditz [:dveditz]]

Argh -- this is worse than the original bug 292624. Originally the error pages
themselves were not privileged, but you could jump from there to a privileged
context. Now it *is* privileged. If you've found an XSS bug you don't need to go
any further than the error page itself :-(

test: in the location bar enter

javascript:try{alert(Components.stack)}catch(e){alert(e)};void(0)

Comment 9

[shutdown]

(In reply to comment #8)
> Argh -- this is worse than the original bug 292624. Originally the error pages
> themselves were not privileged, but you could jump from there to a privileged
> context. Now it *is* privileged. If you've found an XSS bug you don't need to go
> any further than the error page itself :-(
> test: in the location bar enter
> javascript:try{alert(Components.stack)}catch(e){alert(e)};void(0)

When bug 292624 was reported (2005-05-02), the error pages were not privileged.
When bug 300003 was reported (2005-07-07), the error pages were privileged.
Now, the error pages have lost their privileges again.

p=error pages are privileged, l=error page can load chrome, u=error page url

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050501 Firefox/1.0+
p=0 l=1 u=chrome://global/content/netError.xhtml?...
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050623 Firefox/1.0+ (2005062310)
p=0 l=1 u=chrome://global/content/netError.xhtml?...
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050623 Firefox/1.0+ (2005062312)
p=1 l=1 u=chrome://global/content/netError.xhtml?...
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050715 Firefox/1.0+
p=0 l=0 u=about:neterror?...

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&
module=MozillaTinderboxAll&branch=HEAD&branchtype=match&
sortby=Date&hours=2&date=explicit&mindate=2005-06-23+10%3A00&
maxdate=2005-06-23+12%3A00&cvsroot=%2Fcvsroot
I think that nsChromeProtocolHandler.cpp  rev 1.07 gave
privileges to the former (chrome://netError.xhtml) error pages.

Comment 10

[Hixie (not reading bugmail)]

This bug should simply be a matter of making whatever check we do for preventing
about:blank->about:config also apply to about:neterror->about:config.

Comment 11

[Daniel Veditz [:dveditz]]

Attachment: make about:neterror? safe

I notice plain "about:" is not in this list, and does allow loading privileged
about:config etc. should it be added to this list, too?

Comment 12

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 190905 [details] [diff] [review]
make about:neterror? safe

sorry... I'm not a super-reviewer... (but the patch does look right to me)

Comment 13

[Benjamin Smedberg]

Comment on attachment 190905 [details] [diff] [review]
make about:neterror? safe

I'm actually worried about all these EqualsLiteral matches in general... I
believe that we should be using StringBeginsWith or something similar: couldn't
URIs of the form about:blank?foo=bar skip this check?

Comment 14

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 190905 [details] [diff] [review]
make about:neterror? safe

I'll take the sr on this -- bsmedberg, can you mark review (dveditz is about to
answer your question)?

Comment 15

[Daniel Veditz [:dveditz]]

(In reply to comment #13)
> I'm actually worried about all these EqualsLiteral matches in general... I
> believe that we should be using StringBeginsWith or something similar: couldn't
> URIs of the form about:blank?foo=bar skip this check?

Yes, they'd not be counted as "about safe", which means web content couldn't
open them just as they can't open "about:config". If they could be opened then
an attacker could go from there to about:config -- but being able to open them
means about:config could be loaded directly.  Upshot: the EqualsLiterals aren't
exactly right, but they aren't a security problem.

Comment 16

[Benjamin Smedberg]

Comment on attachment 190905 [details] [diff] [review]
make about:neterror? safe

ok

Comment 17

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 190905 [details] [diff] [review]
make about:neterror? safe

sr=shaver (I thought I marked that in Cali!)

Comment 18

[Asa Dotzler [:asa]]

Comment on attachment 190905 [details] [diff] [review]
make about:neterror? safe

who can land this while dveditz is away?

Comment 19

[Mike Connor [:mconnor]]

checked in, branch and trunk.