Some about: urls have chrome privs

VERIFIED FIXED in mozilla0.9.3

Status

()

defect
--
minor
VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: bbaetz, Assigned: security-bugs)

Tracking

Trunk
mozilla0.9.3
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [PDT+], )

Attachments

(2 attachments)

Reporter

Description

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

Comment 1

18 years ago
See also bug 90386, about: document.writes navigator.userAgent.
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.
Assignee: neeti → mstoltz
Keywords: nsBranch
Target Milestone: --- → mozilla0.9.3

Comment 4

18 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
Reporter

Comment 5

18 years ago
r=bbaetz
Fixed on trunk as of today's builds, adding vtrunk.
Status: NEW → ASSIGNED
Keywords: vtrunk
PDT+ from this morning's PDT meeting. Checked in on the branch. 
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Whiteboard: [PDT+]

Comment 9

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

Comment 10

18 years ago
See bug 91779, which was "caused" by this fix.
Reporter

Comment 11

18 years ago
-nsconf, after talking to mstoltz. This isn't directly exploitable, and its been
mentioned in several other bugs anyway (eg 91779)
Group: netscapeconfidential?

Comment 12

18 years ago
ckritzer: pls verify on the branch.
Keywords: vtrunkvbranch
QA Contact: benc → ckritzer

Comment 13

18 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
Status: RESOLVED → VERIFIED

Comment 14

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

Comment 15

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