Bug 1228950 (CVE-2015-7214)

cross-origin restriction bypass & arbitrary local file read using data: and view-source: uri scheme

VERIFIED FIXED in Firefox 43, Firefox OS v2.5

Status

()

Core
DOM
VERIFIED FIXED
3 years ago
a year ago

People

(Reporter: Tsubasa Iinuma, Assigned: bholley)

Tracking

({sec-critical})

Trunk
mozilla45
sec-critical
Points:
---
Bug Flags:
sec-bounty +
qe-verify +

Firefox Tracking Flags

(firefox42 wontfix, firefox43+ verified, firefox44+ verified, firefox45+ verified, firefox-esr3843+ verified, firefox-esr45 fixed, b2g-v2.0 wontfix, b2g-v2.0M wontfix, b2g-v2.1 wontfix, b2g-v2.1S wontfix, b2g-v2.2 affected, b2g-v2.5 fixed, b2g-v2.2r affected, b2g-master fixed)

Details

(Whiteboard: [adv-main43+][adv-esr38.5+])

Attachments

(4 attachments)

(Reporter)

Description

3 years ago
Created attachment 8693479 [details]
poc.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:42.0) Gecko/20100101 Firefox/42.0
Build ID: 20151029151421

Steps to reproduce:

Please access the following page.
http://llamakko:poc@cdc61702-f6af-4568-b485-e8b65871f801.gehirn.ne.jp/poc/

Click the 'CLICK ME!' button.
Wait for about six seconds.


Actual results:

Will display an alert dialog containing the HTML content of example.org.
cross-origin restriction bypass was successful.


Expected results:

If trying to change a protocol to data: uri scheme, that should not be successful.
(Reporter)

Comment 1

3 years ago
Besides I was able to get user's local files by using file scheme instead of http scheme.
(Reporter)

Comment 2

3 years ago
Created attachment 8693500 [details]
etc_passwd.png

file uri scheme version:
http://llamakko:poc@cdc61702-f6af-4568-b485-e8b65871f801.gehirn.ne.jp/poc2/

It works on OSX (and maybe on Linux too).

Updated

3 years ago
Flags: needinfo?(dveditz)

Comment 3

3 years ago
Going to take the liberty of setting this to sec-high (though maybe it's sec-crit?) per https://wiki.mozilla.org/Security_Severity_Ratings and needinfo'ing some other folks who would know more than me about how to fix this. Also moving to DOM for now, though it could be this needs to be somewhere else in Core.
Group: firefox-core-security → core-security
Status: UNCONFIRMED → NEW
Component: Untriaged → DOM
Ever confirmed: true
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bobbyholley)
Keywords: sec-high
Product: Firefox → Core

Updated

3 years ago
Summary: cross-origin restriction bypass using data: and view-source: uri scheme → cross-origin restriction bypass & arbitrary local file read using data: and view-source: uri scheme

Comment 4

3 years ago
Jan, I'm told you might have insights here, and I'm assuming there's a better chance you're already awake. Can you have a look? I'm not seeing us hit the AutoEnterPolicy proxy stuff which throws errors here in the "normal" case of accessing document on a cross-origin iframe's contentWindow. Presumably not a regression from bug 1125423 because I can reproduce with the poc on 43.
Flags: needinfo?(dveditz) → needinfo?(jdemooij)
(Assignee)

Comment 5

3 years ago
Investigating.
Assignee: nobody → bobbyholley
Flags: needinfo?(jdemooij)
Flags: needinfo?(bzbarsky)
Flags: needinfo?(bobbyholley)
So this is moderately exciting.

We have an nsHostObjectURI which has an mScheme of "view-source" and an mPath of "view-source:http://example.org".

As a result of the scheme, it creates a view-source channel, which stashes that URI as its mOriginalURI.  It then passes that URI to SetOriginalURI() on its mChannel (see nsViewSourceChannel::Init), which is another view-source channel (because view-source just grabs the mPath and treats it as a URI).

We end up doing the http://example.org load and so forth, then create a document for that view-source:http://example.org bit, but the principal it gets is the original principal of the page, because the nsHostObjectURI is a uri-with-principal and carries its principal around with itself.

I think comment 0 is right and we should simply forbid changing the scheme on an nsHostObjectURI....
(Assignee)

Comment 7

3 years ago
Thanks for taking a look Boris. I was most of the way through sorting this one out and then got sidetracked with some administrative overhead.

Plan sounds good. I'll post a patch.
(Assignee)

Comment 8

3 years ago
Created attachment 8694577 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI. v1
Attachment #8694577 - Flags: review?(bzbarsky)
Comment on attachment 8694577 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI. v1

r=me
Attachment #8694577 - Flags: review?(bzbarsky) → review+
(Assignee)

Comment 10

3 years ago
Comment on attachment 8694577 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI. v1

[Security approval request comment]
How easily could an exploit be constructed based on the patch?

The patch definitely indicates what the problem is, though it might take some amount of expertise to figure out exactly how to exploit it (or maybe not).

Do comments in the patch, the check-in comment, or tests included in the patch paint a bulls-eye on the security problem?

Sorta.

Which older supported branches are affected by this flaw?

All.

Do you have backports for the affected branches? If not, how different, hard to create, and risky will they be?

Should be identical.

How likely is this patch to cause regressions; how much testing does it need?

Low risk.
Attachment #8694577 - Flags: sec-approval?
I'm pretty sure this is a week too late to take in the Beta branch (and therefore into 43). NI? release management to confirm.
Flags: needinfo?(rkothari)
Flags: needinfo?(lhenry)
Comment on attachment 8694577 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI. v1

sec-approval+.

You need to nom for Aurora, Beta, and ESR38 (assuming it applies to these since no affected tags are marked). Lizzard says she's approving uplifts right now.
Flags: needinfo?(bobbyholley)
Attachment #8694577 - Flags: sec-approval? → sec-approval+
We still have 43 beta 9 building tomorrow, so we could take this.  RC build will be Monday (during the work week).
status-firefox42: --- → wontfix
status-firefox43: --- → affected
status-firefox44: --- → affected
status-firefox45: --- → affected
status-firefox-esr38: --- → affected
tracking-firefox43: --- → +
tracking-firefox44: --- → +
tracking-firefox45: --- → +
tracking-firefox-esr38: --- → 43+
(Assignee)

Comment 14

3 years ago
Comment on attachment 8694577 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI. v1

Approval Request Comment
[Feature/regressing bug #]: Longstanding, I think
[User impact if declined]: XSS
[Describe test coverage new/current, TreeHerder]: None, aside from the testcase in this bug.
[Risks and why]: Pretty low risk. This basically just prevents setting something that is nonsensical to set, and never should have been settable in the first place.
[String/UUID change made/needed]: None.
Flags: needinfo?(bobbyholley)
Attachment #8694577 - Flags: approval-mozilla-esr38?
Attachment #8694577 - Flags: approval-mozilla-beta?
Attachment #8694577 - Flags: approval-mozilla-aurora?
(Reporter)

Comment 16

3 years ago
As a supplemental explanation, view-source uri scheme has a valid status cookies, and so by using it, it's possible to steal information after a cookies has been set.
e.g. name, address, phone number, and so on.
https://hg.mozilla.org/mozilla-central/rev/d873179a7da0
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-b2g-master: --- → fixed
status-firefox45: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
Comment on attachment 8694577 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI. v1

Please uplift to aurora and beta, this should make it into beta 9.
Flags: needinfo?(lhenry)
Attachment #8694577 - Flags: approval-mozilla-beta?
Attachment #8694577 - Flags: approval-mozilla-beta+
Attachment #8694577 - Flags: approval-mozilla-aurora?
Attachment #8694577 - Flags: approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/dfee45543a95
status-firefox44: affected → fixed
Liz already a+'d the aurora uplift so we are good.
Flags: needinfo?(rkothari)
Group: core-security → core-security-release
Attachment #8693479 - Attachment mime type: application/zip → application/x-jar
What code is/was calling SetScheme here?
> What code is/was calling SetScheme here?

This bit in the testcase:

  iframe.contentWindow.location.protocol="view-source"
Flags: qe-verify+
This is a sec-high nominated but not approved yet for ESR38. This needs to be approved to land and go in by release management.
Flags: needinfo?(sledru)
Flags: needinfo?(lhenry)
Whiteboard: [adv-main43+]
(Reporter)

Comment 27

3 years ago
Is this bug fixed in not sec-critical but sec-high?
As far as I looked at the vulnerability information of mfsa2015-78 (sec-critical) on your advisory, this bug can happen similar effects on users computer, i.e., same origin bypassing and local file stealing. 

Also, this bug is not set sec-bounty flag.
Can I get the reward...?
Comment on attachment 8694577 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI. v1

Taking it for the next ESR.
Flags: needinfo?(sledru)
Attachment #8694577 - Flags: approval-mozilla-esr38? → approval-mozilla-esr38+
Flags: needinfo?(lhenry)
problems when uplifting this to esr38:

grafting 318497:cf98f0335f05 "Bug 1228950 - Disallow scheme sets on nsHostObjectURI. r=bz a=lizzard"
merging dom/base/nsHostObjectURI.cpp
merging dom/base/nsHostObjectURI.h
warning: conflicts while merging dom/base/nsHostObjectURI.cpp! (edit, then use 'hg resolve --mark')
abort: unresolved conflicts, can't continue
(use hg resolve and hg graft --continue)
Flags: needinfo?(bobbyholley)
(In reply to Tsubasa Iinuma from comment #27)

> Also, this bug is not set sec-bounty flag.
> Can I get the reward...?

Per instructions at https://www.mozilla.org/en-US/security/client-bug-bounty/ , you're supposed to email security@mozilla.org if you want a bug considered for the bounty. I'll mark it but please email us in the future.
Flags: sec-bounty?
Alias: CVE-2015-7214
(Reporter)

Comment 31

3 years ago
(In reply to Al Billings [:abillings] from comment #30)

> Per instructions at
> https://www.mozilla.org/en-US/security/client-bug-bounty/ , you're supposed
> to email security@mozilla.org if you want a bug considered for the bounty.
> I'll mark it but please email us in the future.

Thank you for your reply, and putting sec-bounty flag.
I will do that!
I was able to reproduce this issue on Firefox 42 RC (20151029151421) using Windows 10 64-bit.

The HTML content is no longer displayed on Firefox 45.0a1 (2015-12-08), Firefox 44.0a2 (2015-12-08) and Firefox 43 RC (20151208100201) under Windows 10 64-bit, Mac OS X 10.11.1 and Ubuntu 13.10 64-bit.
See screenshot: http://i.imgur.com/kmAv7hm.jpg

Tsubasa, could you please confirm that this is the intended behaviour?
Flags: needinfo?(llamakko)
(Reporter)

Comment 33

3 years ago
Yes, This is the intended behaviour!
I also confirmed the same screen is displayed.
Flags: needinfo?(llamakko)
Thanks Tsubasa for your answer!

Based on Comment 32 and Comment 33, I am marking this bug as Verified.
Status: RESOLVED → VERIFIED
status-firefox43: fixed → verified
status-firefox44: fixed → verified
status-firefox45: fixed → verified
(In reply to Tsubasa Iinuma from comment #27)
> Is this bug fixed in not sec-critical but sec-high?
> As far as I looked at the vulnerability information of mfsa2015-78
> (sec-critical) on your advisory, this bug can happen similar effects

You're right, severity corrected.
Flags: needinfo?(dveditz)
Keywords: sec-high → sec-critical
Flags: sec-bounty? → sec-bounty+
(Assignee)

Comment 36

3 years ago
Created attachment 8698124 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI on esr38. r=bz

ESR38 Uplift.
Attachment #8698124 - Flags: review+
(Assignee)

Updated

3 years ago
Flags: needinfo?(bobbyholley)
Comment on attachment 8698124 [details] [diff] [review]
Disallow scheme sets on nsHostObjectURI on esr38. r=bz



Approved, we need this fix in esr38, sec-critical.
Attachment #8698124 - Flags: approval-mozilla-esr38+
https://hg.mozilla.org/releases/mozilla-esr38/rev/57d0fb011812
status-b2g-v2.0: --- → wontfix
status-b2g-v2.0M: --- → wontfix
status-b2g-v2.1: --- → wontfix
status-b2g-v2.1S: --- → wontfix
status-b2g-v2.2: --- → affected
status-b2g-v2.2r: --- → affected
status-firefox-esr38: affected → fixed
status-firefox-esr45: --- → fixed
Whiteboard: [adv-main43+] → [adv-main43+][adv-esr38.5+]
Confirmed fixed on Firefox 38.5.0 ESR (20151214153240) under Ubuntu 14.04 32-bit, Windows 10 64-bit and Mac OS X 10.11.1.
status-firefox-esr38: fixed → verified
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.