Note: There are a few cases of duplicates in user autocompletion which are being worked on.
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)

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?
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
(Assignee)

Comment 5

9 years ago
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.
(Assignee)

Comment 7

9 years ago
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-
(Assignee)

Comment 9

9 years ago
Created attachment 334998 [details] [diff] [review]
Fix
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #334998 - Flags: superreview?
Attachment #334998 - Flags: review?(dveditz)
(Assignee)

Updated

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

Updated

9 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]
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+
(Assignee)

Comment 11

9 years ago
Pushed changeset fddfa9210e76.
Depends on: 424484
Flags: in-testsuite?
(Assignee)

Comment 12

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

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

Approved for 1.9.0.3, a=dveditz for release-drivers
(Assignee)

Comment 14

9 years ago
Actually, this was changeset 0e630c354e2b.

Fixed on branch.
Keywords: fixed1.9.0.3
bz, should this be marked fixed?
(Assignee)

Comment 16

9 years ago
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
Alias: CVE-2008-5015
Group: core-security
(Assignee)

Updated

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