1.33 KB, application/zip
499 bytes, text/plain
673 bytes, application/zip
1.13 KB, patch
|Details | Diff | Splinter Review|
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
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 which calls matchesWindow(), which I think ends calling WebExtensionContentScript::MatchesURI here . 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 ) 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.  https://searchfox.org/mozilla-central/source/toolkit/components/extensions/ExtensionContent.jsm#847  https://searchfox.org/mozilla-central/source/toolkit/components/extensions/WebExtensionPolicy.cpp#414  https://bugzilla.mozilla.org/show_bug.cgi?id=1371786#c47
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
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.
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.
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
Resolution: DUPLICATE → ---
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.
(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).
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.
Summary: Some built-in content handler pages are accessible by WebExtensions → Content scripts sometimes match the document URI rather than the principal URI
Attachment #8965161 - Flags: review?(mixedpuppy)
Assignee: nobody → kmaglione+bmo
Status: REOPENED → ASSIGNED
(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+
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?
https://hg.mozilla.org/integration/mozilla-inbound/rev/07ab807639ee42a407a9bdb0d374206c0f17678d Bug 1436482: Always use the principal URI as the principal URI. r=mixedpuppy
Status: ASSIGNED → RESOLVED
Last Resolved: a year ago → a 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+
status-firefox60: affected → fixed
(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?
(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.
Group: toolkit-core-security → core-security-release
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?
I think you want to try the PoC from bug 1451276 as well, it is a somewhat different scenario.
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
You need to log in before you can comment on or make changes to this bug.