Closed Bug 447579 (CVE-2008-5015) Opened 13 years ago Closed 13 years ago

[FIX]file: URIs inherit chrome privs if opened from chrome


(Core :: Security: CAPS, defect)

Not set





(Reporter: dveditz, Assigned: bzbarsky)


(Depends on 1 open bug)


(Keywords: regression, verified1.9.0.4, verified1.9.1, Whiteboard: [sg:moderate] post 1.8 branch)


(1 file)

the security alias received a report from Luke Bryan that file: URIs are given chrome privileges if opened in the same tab as a chrome (or privileged about:) page. This does not happen in the latest Firefox

 1. create a local file that contains the following script:
    try{ alert((Components.classes) ? "Chrome -- bad!" : "Invalid test"); }
    catch (e) { alert( "Not chrome -- good!"); throw (e); } 
 2. open about:config
 3. in the same tab open the file created in step 1.

The first step is to get a regression range. It would be ironic if it were my bug 230606 "restrict file: abilities" fix.
Flags: wanted1.8.1.x-
Flags: blocking1.9.1?
Flags: blocking1.9.0.2?
To exploit this you have to
 1. get attack code saved locally
 2. get a user to open a privileged about or chrome: URI
 3. convince the user to open the local file

It seems a tall order, but I wouldn't rule it out completely. Our MFSA 2008-35 advisory, for example, described a Safari+Firefox blended threat that accomplished 1 and 2 (now fixed).
Whiteboard: [sg:moderate]
Flags: wanted1.9.0.x+
More likely a regression from bug 435362.
Yeah, a local backout confirms that. Does a docshell know if its current document is a chrome document? It seems like we shouldn't inherit for a file URI if our current document is chrome.
Blocks: 435362
No longer blocks: 433328
I thought we weren't supposed to inherit unless the URI we're linked from was itself a file:// URI.  Did this check get lost?
It looks like that code was removed with the followup checkin for bug 402983.
Or rather it got moved into CheckMayLoad, but in this case we're not calling nsPrincipal::CheckMayLoad.
Flags: blocking1.9.1? → blocking1.9.1+
Dan, this needs an owner. I believe CAPS is you... Not going to block on it for now.
Flags: blocking1.9.0.3?
Flags: blocking1.9.0.2?
Flags: blocking1.9.0.2-
Attached patch FixSplinter Review
Assignee: nobody → bzbarsky
Attachment #334998 - Flags: superreview?
Attachment #334998 - Flags: review?(dveditz)
Attachment #334998 - Flags: superreview? → superreview?(jst)
Summary: file: URIs inherit chrome privs if opened from chrome → [FIX]file: URIs inherit chrome privs if opened from chrome
Whiteboard: [sg:moderate] → [sg:moderate][needs r/sr dveditz/jst]
Comment on attachment 334998 [details] [diff] [review]

Attachment #334998 - Flags: review?(dveditz) → review+
Whiteboard: [sg:moderate][needs r/sr dveditz/jst] → [sg:moderate][needs sr=jst]
Attachment #334998 - Flags: superreview?(jst) → superreview+
Pushed changeset fddfa9210e76.
Depends on: 424484
Flags: in-testsuite?
Comment on attachment 334998 [details] [diff] [review]

We should take this on branch.
Attachment #334998 - Flags: approval1.9.0.3?
Flags: blocking1.9.0.3? → blocking1.9.0.3+
Whiteboard: [sg:moderate][needs sr=jst] → [sg:moderate] post 1.8 branch
Version: unspecified → Trunk
Attachment #334998 - Flags: approval1.9.0.3? → approval1.9.0.3+
Comment on attachment 334998 [details] [diff] [review]

Approved for, a=dveditz for release-drivers
Actually, this was changeset 0e630c354e2b.

Fixed on branch.
Keywords: fixed1.9.0.3
bz, should this be marked fixed?
Uh, yes.  ;)
Closed: 13 years ago
Resolution: --- → FIXED
Verified for with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv: Gecko/2008102304 GranParadiso/3.0.4pre.
Verified for trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081023 Minefield/3.1b2pre.
Alias: CVE-2008-5015
Group: core-security
Keywords: fixed1.9.1
Target Milestone: --- → mozilla1.9.1b1
Keywords: verified1.9.1
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.