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
Target Milestone: --- → mozilla0.9.3
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
Fixed on trunk as of today's builds, adding vtrunk.
Status: NEW → ASSIGNED
PDT+ from this morning's PDT meeting. Checked in on the branch.
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
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.
See bug 91779, which was "caused" by this fix.
-nsconf, after talking to mstoltz. This isn't directly exploitable, and its been mentioned in several other bugs anyway (eg 91779)
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
>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?
> 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.