Bug 447579 (CVE-2008-5015)

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

VERIFIED FIXED in mozilla1.9.1b1

Status

()

Core
Security: CAPS
--
major
VERIFIED FIXED
9 years ago
9 years ago

People

(Reporter: dveditz, Assigned: bz)

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

9 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

9 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+
This regressed between 2008-05-28 and 2008-05-29:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-05-28+04&maxdate=2008-05-29+09&cvsroot=%2Fcvsroot
I think a regression from bug 433328.
Blocks: 433328
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.

Updated

9 years ago
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-
Created attachment 334998 [details] [diff] [review]
Fix
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
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]
(Reporter)

Comment 10

9 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]

Updated

9 years ago
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

9 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

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

Comment 13

9 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: 9 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

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

Updated

9 years ago
Group: core-security
Keywords: fixed1.9.1
Target Milestone: --- → mozilla1.9.1b1

Updated

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