Bug 447579 (CVE-2008-5015)

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

VERIFIED FIXED in mozilla1.9.1b1

Status

()

--
major
VERIFIED FIXED
11 years ago
10 years ago

People

(Reporter: dveditz, Assigned: bzbarsky)

Tracking

(Depends on: 1 bug, {regression, verified1.9.0.4, verified1.9.1})

Trunk
mozilla1.9.1b1
regression, verified1.9.0.4, verified1.9.1
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.1 +
blocking1.9.0.2 -
blocking1.9.0.4 +
wanted1.9.0.x +
wanted1.8.1.x -
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:moderate] post 1.8 branch)

Attachments

(1 attachment)

(Reporter)

Description

11 years ago
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 2.0.0.17pre.

Steps:
 1. create a local file that contains the following script:
  <script>
    try{ alert((Components.classes) ? "Chrome -- bad!" : "Invalid test"); }
    catch (e) { alert( "Not chrome -- good!"); throw (e); } 
  <script>
 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?
(Reporter)

Comment 1

11 years ago
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-
Posted patch FixSplinter Review
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #334998 - Flags: superreview?
Attachment #334998 - Flags: review?(dveditz)
(Assignee)

Updated

11 years ago
Attachment #334998 - Flags: superreview? → superreview?(jst)
(Assignee)

Updated

11 years ago
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]
(Reporter)

Comment 10

11 years ago
Comment on attachment 334998 [details] [diff] [review]
Fix

r=dveditz
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]
Fix

We should take this on branch.
Attachment #334998 - Flags: approval1.9.0.3?
(Reporter)

Updated

11 years ago
Flags: blocking1.9.0.3? → blocking1.9.0.3+
Whiteboard: [sg:moderate][needs sr=jst] → [sg:moderate] post 1.8 branch
Version: unspecified → Trunk
(Reporter)

Updated

11 years ago
Attachment #334998 - Flags: approval1.9.0.3? → approval1.9.0.3+
(Reporter)

Comment 13

11 years ago
Comment on attachment 334998 [details] [diff] [review]
Fix

Approved for 1.9.0.3, 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.  ;)
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Verified for 1.9.0.4 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4pre) Gecko/2008102304 GranParadiso/3.0.4pre.
Keywords: fixed1.9.0.4 → verified1.9.0.4
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.
Status: RESOLVED → VERIFIED
(Reporter)

Updated

11 years ago
Alias: CVE-2008-5015
(Reporter)

Updated

11 years ago
Group: core-security
(Assignee)

Updated

10 years ago
Keywords: fixed1.9.1
Target Milestone: --- → mozilla1.9.1b1

Updated

10 years ago
Keywords: verified1.9.1
Keywords: fixed1.9.1
You need to log in before you can comment on or make changes to this bug.