Closed Bug 338037 Opened 18 years ago Closed 18 years ago

chrome://global/content/jar: can load remote chrome


(Toolkit :: Startup and Profile System, defect)

Not set





(Reporter: dveditz, Assigned: benjamin)




(Keywords: fixed1.8.1, verified1.8.0.5, Whiteboard: [sg:moderate])


(2 files, 2 obsolete files)

Spun off from bug 337744 comment 6, chrome URLs can syntactically wrap arbitrary protocols and confer chrome privs! some don't work, but wrapping them in jar: does.

Luckily we block web content from directly loading chrome URLs as content, but it would be pretty easy to get a fair number of people to copy or drag a "broken" link to the address bar to get at content they really wanted (download the latest movie or music, free pr0n, etc).

> chrome://global/content/ does *not* work, because
> of the channel-unwinding checks at
> But if remote content were loaded from a JAR file it would work, e.g.:
> chrome://global/content/jar:!/somefile
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Flags: blocking1.8.0.5?
Load the testcase unprivileged as

Load the testcase with chrome privileges as

Assigning "moderate" severity because of the required user-interaction, but if someone discovered a way to bypass checkLoadURI and find a way for web content to load chrome this would be "critical".

Anyone know a better bugzilla component for the chrome registry code? The description for XP Miscellany says "COMPONENT RETIRED. Please do not file bugs here." But this isn't a XUL bug, nor does this code live in Networking although it is related to URL processing. The "Core" product does not support any other  general category.
Flags: blocking1.8.0.4?
Flags: blocking1.7.14?
Flags: blocking-aviary1.0.9?
Summary: chrome:/jar:http: urls can wrap other protocols → chrome://global/content/jar: can load remote chrome
Whiteboard: [sg:moderate]
Mozilla 1.7 may not have this bug or it may be manifested differently (even ff 1.0.x may have different manifestations), because of the different revisions and forks of chrome registry code involved.
Component: XP Miscellany → XRE Startup
Flags: blocking1.8.1?
Flags: blocking1.7.14?
Product: Core → Toolkit
QA Contact: brendan → xre.startup
Attached patch Make colon an illegal character (obsolete) — Splinter Review
This should be pretty safe and simple. Darin, if you can review ASAP, we're thinking about respinning for this.
Assignee: nobody → benjamin
Attachment #222099 - Flags: first-review?(darin)
Attachment #222099 - Flags: approval1.8.0.4?
Attachment #222099 - Flags: approval-branch-1.8.1?(darin)
Yeah, but FF2 definitely has this issue.

I can't seem to reproduce with that testcase in trunk Seamonkey, but I'm not sure whether that's just a matter of needing URI syntax tweaks or a genuine chrome registry difference.
Flags: blocking-thunderbird2?
Flags: blocking-firefox2?
Wouldn't that prevent the use of ':' in filenames too?  Would it make more sense to error out if NS_NewURI on some substring succeeds, since that's the case we really care about as far as I can tell?
I believe colons aren't legal characters in windows filenames anyway, and I'm worried about performance and reentrancy issue having to call NS_NewURI all the time.
But don't chrome URLs support query and reference fragments?  If we are going to restrict ':' then that should only apply to the file path.  Isn't it possible that chrome apps are using "chrome://foo/bar.xul?x=y:z" for stuff?
> Isn't it possible that chrome apps are using "chrome://foo/bar.xul?x=y:z" for stuff?



Also, what about escaped colons.  Do we need to worry about those too?
Attached patch Use NS_NewURI (obsolete) — Splinter Review
This uses NS_NewURI to check for absolute URIs. I still prefer the first version, but I understand the concern with query strings.

I'll also look at colon-checkin just the path (not sure which would be more efficient).
Attachment #222149 - Flags: first-review?(darin)
Attached patch Use GetFilePathSplinter Review
I think that this is probably the most-correct. BTW, the documentation of .filePath, .directory in nsIURL.idl is incorrect.
Attachment #222099 - Attachment is obsolete: true
Attachment #222149 - Attachment is obsolete: true
Attachment #222154 - Flags: first-review?(darin)
Attachment #222149 - Flags: first-review?(darin)
Attachment #222099 - Flags: first-review?(darin)
Attachment #222099 - Flags: approval1.8.0.4?
Attachment #222099 - Flags: approval-branch-1.8.1?(darin)
Comment on attachment 222154 [details] [diff] [review]
Use GetFilePath

I think you should add some comments explaining why these checks
are necessary.  In what way is nsIURL's documentation incorrect?

Attachment #222154 - Flags: first-review?(darin) → first-review+
Fixed on trunk.
Closed: 18 years ago
Resolution: --- → FIXED
Flags: blocking1.9a1?
Flags: blocking1.9a1+
Flags: blocking1.8.0.5?
Flags: blocking1.8.0.5+
Flags: blocking-thunderbird2?
Flags: blocking-thunderbird2+
Flags: blocking-firefox2?
Flags: blocking-firefox2+
Attachment #222154 - Flags: approval1.8.0.5?
Attachment #222154 - Flags: approval1.8.0.4?
Attachment #222154 - Flags: approval-branch-1.8.1?(darin)
Attachment #222154 - Flags: approval-branch-1.8.1?(darin) → approval-branch-1.8.1+
Fixed on 1.8 branch
Keywords: fixed1.8.1
This does not appear to be a problem in Firefox 1.0.x or the Mozilla 1.7 series. I caused this in bug 278534, where I changed nsChromeRegistry::ConvertChromeURL from using string manipulation to resolving against the baseuri.
perhaps we should verify that the URL resulting from URL resolution is still a chrome: URL?
Flags: blocking-aviary1.0.9? → blocking-aviary1.0.9-
Except it's not, it's typically a jar:file:/// url.
Flags: blocking1.8.0.4?
Comment on attachment 222154 [details] [diff] [review]
Use GetFilePath

unfortunately missed the train by a couple weeks, and we didn't do a respin we could slip this into.
Attachment #222154 - Flags: approval1.8.0.4?
Comment on attachment 222154 [details] [diff] [review]
Use GetFilePath

We need to get this into
Comment on attachment 222154 [details] [diff] [review]
Use GetFilePath

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #222154 - Flags: approval1.8.0.5? → approval1.8.0.5+
Fixed on MOZILLA_1_8_0_BRANCH
Keywords: fixed1.8.0.5
v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US;
rv: Gecko/20060626 Firefox/, permission denied for alert testcase.
Group: security
Flags: in-testsuite?
Component: XRE Startup → Startup and Profile System
QA Contact: xre.startup → startup
You need to log in before you can comment on or make changes to this bug.