Bug 1436482 (CVE-2018-5172)

Content scripts sometimes match the document URI rather than the principal URI

VERIFIED FIXED in Firefox 60

Status

P1
normal
VERIFIED FIXED
a year ago
6 months ago

People

(Reporter: qab, Assigned: kmag)

Tracking

(Depends on: 1 bug, {csectype-priv-escalation, sec-moderate})

60 Branch
mozilla61
csectype-priv-escalation, sec-moderate
Dependency tree / graph
Bug Flags:
sec-bounty +

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox59 wontfix, firefox60 verified, firefox61 verified)

Details

(Whiteboard: [adv-main60+][post-critsmash-triage])

Attachments

(4 attachments)

(Reporter)

Description

a year ago
Posted file feedPreviewPoC.xpi
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce:

1. Install attached PoC extension
2. Once a page appears, click on the button.
3. A prompt will appear, paste by hitting (CTRL+V) then hit 'Enter'
4. Executable file is downloaded and executed.

This is just an example on one content handler, you can do the same with PDFs. Interestingly, JSON previewer cannot have code injected to it.


Actual results:

Injected JS into feed preview which results in RCE with user interaction. 
Video: https://youtu.be/TRrdmuaFzuQ



Expected results:

In bug 1422231 I described how the feed reader preview page can be clickjacked to run arbitrary executable files. Although these previews are not accessible to web, they are for webextensions. This is bad because usually these have other API's that may be used to escalate privilege.
Component: WebExtensions: Untriaged → WebExtensions: General
Keywords: csectype-priv-escalation, sec-moderate
(Reporter)

Comment 1

a year ago
Posted file content.php
I forgot one thing, in the PoC background.js I reference 'http://localhost:8080/content.php' 

I attached it, all it does is return a content-type of 'application/vnd.mozilla.maybe.feed'
About:feeds and about:reader are both content privileged chrome pages which are used to display feeds and pdf content respectively. My guess of the cause here is that browser.tabs.execute checks the URI of the page, and both about:feeds and about:reader show the URI of the remote content they are displaying. I don't know if URI is the right term here, but I tested with other content privileged about: pages (e.g. about:certerror, about:home) but the script was not injected in those cases. Feeds and Reader are the only two pages that I know which exhibit this URI rewriting behavior. Im not sure why JSON viewer is different, but one thing is that JSON view isn't enabled when the document is framed, so that might explain that. 

From what I can tell, tabs.execute() is here[1] which calls matchesWindow(), which I think ends calling WebExtensionContentScript::MatchesURI here [2].

In terms of impact, about:feeds was rewritten last year defensively, so bug 1422231 aside, I'm not sure there is much an extension could do here other than subscribe you to feeds. Reader I spent a lot of time looking into whether or not it would be safe injecting into about:reader and we ended up denying access to this (or so we thought) so this is definitely a loophole (see [3]) but probably not an easily exploitable. My gut is that this is a sec-low, but since we explicitly decided NOT to give extensions access to reader mode, and this bug contravenes that decision, I'm fine with leaving as sec-moderate, mainly for the risk that this issue might be chained with others.


[1] https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ExtensionContent.jsm#847 
[2] https://searchfox.org/mozilla-central/source/toolkit/components/extensions/WebExtensionPolicy.cpp#414
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1371786#c47
Flags: needinfo?(aswan)
The POC is based on being able to inject scripts into about: pages, which is already covered by an existing bug.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1431371
Flags: needinfo?(aswan)
(Reporter)

Comment 4

a year ago
Bug 1431371 is relying on the activeTab permission whilst this bug is only asking for permission for the website a pdf/xml is hosted on. The PoC in 1431371 doesn't work anymore yet the PoC here still works. 

I am pretty sure these are two different bugs, please re-open.
Flags: needinfo?(aswan)
(Reporter)

Comment 5

a year ago
Would like to clarify. The PoC here in comment 0 does contain extra permissions (including activeTab) but its not used. The only thing that is important is a host permission for a website that will have a pdf/atom file hosted, you could just leave <all_urls> in the permission and the poc will work.
(Reporter)

Comment 6

a year ago
The original PoC will not work due to bug 1445106 making it so that you can't embed feed reader. Though the main bug still exists, we can execute arbitrary JS from webextension if we open a tab with a feed reader preview.

This bug is still not fixed and is falsely marked as resolved as duplicate.
Do you have another PoC that works?
Status: RESOLVED → REOPENED
Ever confirmed: true
Flags: sec-bounty?
Resolution: DUPLICATE → ---
(Assignee)

Comment 8

a year ago
If all that matters is that the extension has permissions for a web origin, then this is not an extension bug. An ordinary website can get access to same-origin content windows as easily as an extension content script can.
(Reporter)

Comment 9

a year ago
Posted file New PoC
(In reply to Kris Maglione [:kmag] (long backlog; ping on IRC if you're blocked) from comment #8)
> If all that matters is that the extension has permissions for a web origin,
> then this is not an extension bug. An ordinary website can get access to
> same-origin content windows as easily as an extension content script can.

When you open a same-origin PDF or feed reader you can't access it from the opener, it's treat cross-origin since technically the built-in content handler is a semi-privileged about: URL. Refer to comment 2 for a detailed explanation. 


I have attached a new version of the PoC and I am using content_scripts this time to inject JS into contexts we're not supposed to (feed reader).
(Reporter)

Updated

a year ago
Flags: needinfo?(aswan)
(Reporter)

Comment 10

a year ago
Would like to point out something that may help in fixing this. I mentioned that the JSON previewer is unaffected by this and it's not because the previewer doesn't display when framed. Because even if we just open a tab with a hosted JSON that we have permission to execute JS in, we can't execute anything.

So it seems like JSON previewer is doing something right here that needs to be done with the others.
(Assignee)

Updated

a year ago
Summary: Some built-in content handler pages are accessible by WebExtensions → Content scripts sometimes match the document URI rather than the principal URI
(Assignee)

Updated

a year ago
Duplicate of this bug: 1451276
(Assignee)

Comment 12

a year ago
MozReview-Commit-ID: 7oePANQBCxK
Attachment #8965161 - Flags: review?(mixedpuppy)
(Assignee)

Updated

a year ago
Assignee: nobody → kmaglione+bmo
Status: REOPENED → ASSIGNED

Comment 13

a year ago
(In reply to Abdulrahman Alqabandi from comment #10)
> So it seems like JSON previewer is doing something right here that needs to
> be done with the others.

The JSON viewer explicitly downgrades itself to a null principal, unlike e.g. pdfjs.
Attachment #8949689 - Attachment mime type: application/x-php → text/plain
Attachment #8965161 - Flags: review?(mixedpuppy) → review+
Priority: -- → P1
(Assignee)

Comment 14

a year ago
Comment on attachment 8965161 [details] [diff] [review]
Always use the principal URI as the principal URI

Approval Request Comment
[Feature/Bug causing the regression]: N/A
[User impact if declined]: This bug allows extensions to run scripts on certain semi-privileged places that run with the URLs of ordinary web content pages (pdf.js, for instance). This is a minor privilege escalation, and does not apply to chrome-privileged pages.
[Is this code covered by automated tests?]: The changed code is, though there isn't yet coverage for the vulnerability that was fixed.
[Has the fix been verified in Nightly?]: No.
[Needs manual test from QE? If yes, steps to reproduce]: Described in comment 9 and bug 1451276 comment 0.
[List of other uplifts needed for the feature/fix]: None.
[Is the change risky?]: No.
[Why is the change risky/not risky?]: It is a trivial change that makes us consistently use the principal URL in a place where we inconsistently used it previously.
[String changes made/needed]: None.
Attachment #8965161 - Flags: approval-mozilla-beta?
(Assignee)

Comment 15

a year ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/07ab807639ee42a407a9bdb0d374206c0f17678d
Bug 1436482: Always use the principal URI as the principal URI. r=mixedpuppy
https://hg.mozilla.org/mozilla-central/rev/07ab807639ee
Status: ASSIGNED → RESOLVED
Last Resolved: a year agoa year ago
status-firefox61: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla61
status-firefox59: --- → wontfix
status-firefox60: --- → affected
status-firefox-esr52: --- → unaffected
Comment on attachment 8965161 [details] [diff] [review]
Always use the principal URI as the principal URI

Approved for 60.0b11.
Attachment #8965161 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
(In reply to :Gijs (he/him) from comment #13)
> The JSON viewer explicitly downgrades itself to a null principal, unlike e.g. pdfjs.

Is there any reason the pdf viewer can't do that, too?
Flags: sec-bounty?
Flags: sec-bounty+
Flags: needinfo?(gijskruitbosch+bugs)

Comment 20

11 months ago
(In reply to Daniel Veditz [:dveditz] from comment #19)
> (In reply to :Gijs (he/him) from comment #13)
> > The JSON viewer explicitly downgrades itself to a null principal, unlike e.g. pdfjs.
> 
> Is there any reason the pdf viewer can't do that, too?

See https://bugzilla.mozilla.org/show_bug.cgi?id=1450443#c4 and earlier comments - because it uses postMessage, and you can't really verify origins easily for null principals, it's not straightforward, no.
Flags: needinfo?(gijskruitbosch+bugs)
Group: toolkit-core-security → core-security-release
Whiteboard: [adv-main60+]
Alias: CVE-2018-5172
Flags: qe-verify+
Whiteboard: [adv-main60+] → [adv-main60+][post-critsmash-triage]
Hi Kris,

I was trying to verify this bug but my understanding is that, the original POC from comment 0, will not work in reproducing it. So I've used the new POC from comment 9 instead. I'm not sure however, what would be the expected result in a fixed build; the only difference I see on a fixed build, is the "http://www.feedforall.com/sample.xml" pop-up message which is not displayed anymore when loading the .xpi in FF.

Could you please confirm/infirm if this is the right behavior?
Flags: needinfo?(kmaglione+bmo)
(Reporter)

Comment 22

11 months ago
(In reply to Ciprian Georgiu, QA [:ciprian_georgiu] from comment #21)
> Hi Kris,
> 
> I was trying to verify this bug but my understanding is that, the original
> POC from comment 0, will not work in reproducing it. So I've used the new
> POC from comment 9 instead. I'm not sure however, what would be the expected
> result in a fixed build; the only difference I see on a fixed build, is the
> "http://www.feedforall.com/sample.xml" pop-up message which is not displayed
> anymore when loading the .xpi in FF.
> 
> Could you please confirm/infirm if this is the right behavior?

If the alert box appear it means javascript was executed within sample.xml. If it does not appear then the bug has been fixed.

To be sure, you can open the Web Inspector and look at the debugger tab. Notice the sources of javascript, if you see one coming from an extension then the bug is still working. In latest nightly however it does not appear like any JS was injected and so the bug seems fixed.

Comment 23

11 months ago
I think you want to try the PoC from bug 1451276 as well, it is a somewhat different scenario.
Thanks Abdulrahman, for clarifying this.

I was able to reproduce this bug using an affected Nightly build (2018-02-07), with the PoC from comment 9.

I can confirm that the alert box is not triggered anymore, and in Debugger, there are no sources of javascript coming from the extension. I've tested on latest Nightly 61.0a1 (2018-05-06), RC2 60.0 (20180503143129) running Windows 10 x64, macOS 10.13 and Ubuntu 16.04 x64.

(In reply to Wladimir Palant from comment #23)
> I think you want to try the PoC from bug 1451276 as well, it is a somewhat
> different scenario.

Can you please CC me in the bug, I don't have access.
Flags: needinfo?(kmaglione+bmo)
(Reporter)

Comment 25

11 months ago
Would love a CC on bug 1451276 as well, I'm very curious.
Verified with the PoC from bug 1451276 comment 0 as well, on the same builds and platforms mentioned in comment 24. I can confirm that everything works as described in the dupe bug.

Marking this bug verified fixed per this comment and comment 24.
Status: RESOLVED → VERIFIED
status-firefox60: fixed → verified
status-firefox61: fixed → verified
Flags: qe-verify+

Updated

9 months ago
Product: Toolkit → WebExtensions
Group: core-security-release

Updated

6 months ago
Depends on: 1489312
You need to log in before you can comment on or make changes to this bug.