2.65 KB, application/x-jar
201.79 KB, image/png
2.04 KB, patch
|Details | Diff | Splinter Review|
2.07 KB, patch
|Details | Diff | Splinter Review|
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:firstname.lastname@example.org/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.
Besides I was able to get user's local files by using file scheme instead of http scheme.
file uri scheme version: http://llamakko:email@example.com/poc2/ It works on OSX (and maybe on Linux too).
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
Product: Firefox → Core
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
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: nobody → 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....
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 on attachment 8694577 [details] [diff] [review] Disallow scheme sets on nsHostObjectURI. v1 r=me
Attachment #8694577 - Flags: review?(bzbarsky) → review+
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.
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.
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).
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.
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 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.
Liz already a+'d the aurora uplift so we are good.
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"
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.
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.
Attachment #8694577 - Flags: approval-mozilla-esr38? → approval-mozilla-esr38+
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)
(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 firstname.lastname@example.org if you want a bug considered for the bounty. I'll mark it but please email us in the future.
(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 email@example.com 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?
Yes, This is the intended behaviour! I also confirmed the same screen is displayed.
Thanks Tsubasa for your answer! Based on Comment 32 and Comment 33, I am marking this bug as 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.
Attachment #8698124 - Flags: review+
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+
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.
Component: DOM → DOM: Core & HTML
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.