1228950 - (CVE-2015-7214) cross-origin restriction bypass & arbitrary local file read using data: and view-source: uri scheme

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Tsubasa Iinuma]

Attachment: 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:[e-mail]/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.

Comment 1

[Tsubasa Iinuma]

Besides I was able to get user's local files by using file scheme instead of http scheme.

Comment 2

[Tsubasa Iinuma]

Attachment: etc_passwd.png

file uri scheme version:
http://llamakko:[e-mail]/poc2/

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

Comment 3

[:Gijs (he/him)]

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.

Comment 4

[:Gijs (he/him)]

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.

Comment 5

[Bobby Holley (:bholley)]

Investigating.

Comment 6

[Boris Zbarsky [:bzbarsky]]

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

Comment 7

[Bobby Holley (:bholley)]

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.

Comment 8

[Bobby Holley (:bholley)]

Attachment: Disallow scheme sets on nsHostObjectURI. v1

Comment 9

[Boris Zbarsky [:bzbarsky]]

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

r=me

Comment 10

[Bobby Holley (:bholley)]

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.

Comment 11

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 12

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 13

[Liz Henry (:lizzard) (relman/hg->git project)]

We still have 43 beta 9 building tomorrow, so we could take this.  RC build will be Monday (during the work week).

Comment 14

[Bobby Holley (:bholley)]

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.

Comment 15

[Bobby Holley (:bholley)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d873179a7da0

Comment 16

[Tsubasa Iinuma]

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.

Comment 17

[Tsubasa Iinuma]

Test page:
http://llamakko:[e-mail]/poc3/

Comment 18

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d873179a7da0

Comment 19

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 20

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/dfee45543a95

Comment 21

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-beta/rev/cf98f0335f05

Comment 22

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Liz already a+'d the aurora uplift so we are good.

Comment 23

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

What code is/was calling SetScheme here?

Comment 24

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/releases/mozilla-b2g44_v2_5/rev/dfee45543a95

Comment 25

[Boris Zbarsky [:bzbarsky]]

> What code is/was calling SetScheme here?

This bit in the testcase:

  iframe.contentWindow.location.protocol="view-source"

Comment 26

[Al Billings [:abillings - ex-MoCo]]

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.

Comment 27

[Tsubasa Iinuma]

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 28

[Sylvestre Ledru [:Sylvestre]]

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

Taking it for the next ESR.

Comment 29

[Carsten Book [:Tomcat]]

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)

Comment 30

[Al Billings [:abillings - ex-MoCo]]

(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 [e-mail] if you want a bug considered for the bounty. I'll mark it but please email us in the future.

Comment 31

[Tsubasa Iinuma]

(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 [e-mail] 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!

Comment 32

[Vasilica Tamas, QA [:vtamas]]

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?

Comment 33

[Tsubasa Iinuma]

Yes, This is the intended behaviour!
I also confirmed the same screen is displayed.

Comment 34

[Vasilica Tamas, QA [:vtamas]]

Thanks Tsubasa for your answer!

Based on Comment 32 and Comment 33, I am marking this bug as Verified.

Comment 35

[Daniel Veditz [:dveditz]]

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

Comment 36

[Bobby Holley (:bholley)]

Attachment: Disallow scheme sets on nsHostObjectURI on esr38. r=bz

ESR38 Uplift.

Comment 37

[Liz Henry (:lizzard) (relman/hg->git project)]

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.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr38/rev/57d0fb011812

Comment 39

[Vasilica Tamas, QA [:vtamas]]

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.