1436482 - (CVE-2018-5172) Content scripts sometimes match the document URI rather than the principal URI

Status: VERIFIED FIXED

(WebExtensions :: General, defect, P1)

Description

[Abdulrahman Alqabandi]

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

Comment 1

[Abdulrahman Alqabandi]

Attachment: 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'

Comment 2

[Paul Theriault [:pauljt] (no longer reading bugmail)]

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

Comment 3

[Andrew Swan [:aswan]]

The POC is based on being able to inject scripts into about: pages, which is already covered by an existing bug.

Comment 4

[Abdulrahman Alqabandi]

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.

Comment 5

[Abdulrahman Alqabandi]

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.

Comment 6

[Abdulrahman Alqabandi]

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.

Comment 7

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

Do you have another PoC that works?

Comment 8

[Kris Maglione [:kmag]]

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.

Comment 9

[Abdulrahman Alqabandi]

Attachment: 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).

Comment 10

[Abdulrahman Alqabandi]

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.

Comment 12

[Kris Maglione [:kmag]]

Attachment: Always use the principal URI as the principal URI

MozReview-Commit-ID: 7oePANQBCxK

Comment 13

[:Gijs (he/him)]

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

Comment 14

[Kris Maglione [:kmag]]

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.

Comment 15

[Kris Maglione [:kmag]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/07ab807639ee42a407a9bdb0d374206c0f17678d
Bug 1436482: Always use the principal URI as the principal URI. r=mixedpuppy

Comment 16

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/07ab807639ee

Comment 17

[Ryan VanderMeulen [:RyanVM]]

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

Approved for 60.0b11.

Comment 18

[Ryan VanderMeulen [:RyanVM]]

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

Comment 19

[Daniel Veditz [:dveditz]]

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

Comment 20

[:Gijs (he/him)]

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

Comment 21

[Ciprian Georgiu, Desktop QA]

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?

Comment 22

[Abdulrahman Alqabandi]

(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

[Wladimir Palant]

I think you want to try the PoC from bug 1451276 as well, it is a somewhat different scenario.

Comment 24

[Ciprian Georgiu, Desktop QA]

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.

Comment 25

[Abdulrahman Alqabandi]

Would love a CC on bug 1451276 as well, I'm very curious.

Comment 26

[Ciprian Georgiu, Desktop QA]

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.