Bradley Baetz (:bbaetz) Reporter
	Description • 23 years ago

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.

	Jesse Ruderman
	Comment 1 • 23 years ago

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

	Mitchell Stoltz (not reading bugmail) Assignee
	Comment 2 • 23 years ago

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.

	Chris Waterson
	Comment 4 • 23 years ago

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

	Bradley Baetz (:bbaetz) Reporter
	Comment 5 • 23 years ago

r=bbaetz

	Mitchell Stoltz (not reading bugmail) Assignee
	Comment 7 • 23 years ago

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

	Mitchell Stoltz (not reading bugmail) Assignee
	Comment 8 • 23 years ago

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

	ckritzer (gone)
	Comment 9 • 23 years ago

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.

	Bradley Baetz (:bbaetz) Reporter
	Comment 10 • 23 years ago

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

	Bradley Baetz (:bbaetz) Reporter
	Comment 11 • 23 years ago

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

	lchiang
	Comment 12 • 23 years ago

ckritzer: pls verify on the branch.

	ckritzer (gone)
	Comment 13 • 23 years ago

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

	Frank Tang
	Comment 14 • 23 years ago

>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?

	Bradley Baetz (:bbaetz) Reporter
	Comment 15 • 23 years ago

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.

	Mitchell Stoltz (not reading bugmail) Assignee
	Comment 16 • 23 years ago

> 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.