88087 - Some about: urls have chrome privs

Status: VERIFIED FIXED

(Core :: Networking, defect)

Description

[Bradley Baetz (:bbaetz)]

Some about: urls (about:, about:mozilla, about:plugins) redirect to chrome
documents. This means that the documents have privilages, and since some of them
do document.write, this is possibly exploitable. I couldn't find a way to
exploit it, but I see no reason why about:mozilla needs chrome access anyway. It
might be possible to exploit in combination with other bugs. (eg bug 86147,
omitting details in case this one is fixed and opened up before that bug)

To test:
1. Go to about:
2. in the urlbar (which runs with the permission of the enclosed webpage), type:
javascript:alert(Components.classes);
If you see something, then the doc has chrome access.

Comment 1

[Jesse Ruderman]

See also bug 90386, about: document.writes navigator.userAgent.

Comment 2

[Mitchell Stoltz (not reading bugmail)]

I'll take this, as I have a fix. In concert with some other exploit, known or
unknown, this is potentially serious. Adding nsBranch, I'd like to get this on
the branch too.

Comment 3

[Mitchell Stoltz (not reading bugmail)]

Attachment: A fix - assign a different principal if about: is redirected to chrome:

Comment 4

[Chris Waterson]

We should probably store the resulting channel in a temporary, and only assign
to the out parameter once we clear the security checks. That way, any unchecked
callers won't introduce a potential hole. Otherwise, looks ok. r/sr=waterson

Comment 5

[Bradley Baetz (:bbaetz)]

r=bbaetz

Comment 6

[Mitchell Stoltz (not reading bugmail)]

Attachment: patch v2 - assign the channel to a temp variable so we don't return it on error

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Fixed on trunk as of today's builds, adding vtrunk.

Comment 8

[Mitchell Stoltz (not reading bugmail)]

PDT+ from this morning's PDT meeting. Checked in on the branch. 

Comment 9

[ckritzer (gone)]

VERIFIED FIXED on:
MacOS91 2001-07-20-08-trunk
Win98SE 2001-07-20-08-trunk
LinRH62 2001-07-20-05-trunk

Will check the branch bits when available.

Comment 10

[Bradley Baetz (:bbaetz)]

See bug 91779, which was "caused" by this fix.

Comment 11

[Bradley Baetz (:bbaetz)]

-nsconf, after talking to mstoltz. This isn't directly exploitable, and its been
mentioned in several other bugs anyway (eg 91779)

Comment 12

[lchiang]

ckritzer: pls verify on the branch.

Comment 13

[ckritzer (gone)]

Marking VERIFIED FIXED on:
-MacOS91 2001-07-24-03-0.9.2
-LinRH62 2001-07-24-05-0.9.2
-Win98SE 2001-07-24-06-0.9.2

Comment 14

[Frank Tang]

>I see no reason why about:mozilla needs chrome access anyway.
one reason you need is localizability. We need to access seperate localizable 
files in the chrome directory. 

I don't understand why it will be a security issue to grant chrome access to a 
file which is eventually resolved as a chrome files (about:plugins eventually 
resolved as chrome://...) 

What could possible go wrong if we grant chrome: access to a about: url ? should 
about: protocol and chrome: protocol have the same access privilege?

Comment 15

[Bradley Baetz (:bbaetz)]

ftang: There is no problem with loading the contents of about:mozilla from a
chrome file. The problem was that doing so meant that any javascript run on the
page was run with the system principal, possibly leading to other exploits.

For example, see bug 90386, bug 88167. There were others which could be used to
exploit this.

chrome://global/content/mozilla.html is the about:mozilla page. Anything which
you put there should work, as long as it doesn't require xpconnect access.

Comment 16

[Mitchell Stoltz (not reading bugmail)]

> I don't understand why it will be a security issue to grant chrome access to a 
> file which is eventually resolved as a chrome files

It's a security issue in the case of chrome pages which include content that
could potentially be changed by an attacker. The bugs Bradley mentioned above
were examples of this. There's at least one more besides; I can't find the bug
number right now. This is especially likely when chrome pages are loaded in the
content area. This is a rarity; chrome is usually loaded as window chrome, not
content. Where chrome pages are loaded as content (including about: pages and
FTP/file directory listing pages), we have been plagued with security problems.
This bug cuts those problems off at the knees, at least for about: pages.