1452045 - Race condition allows injecting content scripts into a wrong context

Status: NEW

(WebExtensions :: General, defect, P3)

Description

[Wladimir Palant]

Attachment: Proof of concept extension

Note: My testing indicates that this issue isn't exploitable. I marked it as security-sensitive just in case I am wrong.

If I call tabs.executeScript() on a tab that the extension has access to (e.g. an extension page) and immediately call tabs.update() to navigate this tab away to a different page (including restricted URIs like https://testpilot.firefox.com/), the content script will execute after the navigation to the new page is performed. My proof of concept extension relies on E10S being switched off and cached pages to make timing simpler, but with somewhat more effort the race condition here should be exploitable without such tricks.

Steps to reproduce:

1. Go to about:debugging, make sure that browser.tabs.remote.autostart is switched off and restart browser.
2. Open http://example.com/ to make sure that it is cached.
3. Download the attached proof of concept extension.
4. Go to about:debugging, click "Load Temporary Add-on" and choose the extension file you downloaded.
5. The extension will open a tab and close it immediately.

Expected results:

The extension should either not open a tab with results (content script didn't run) or that tab should say "Running in moz-extension://..." (content script executed in the context of the extension page).

Actual results:

In Firefox 61.0a1 (2018-04-04) nightly on Linux I reliably get "Cannot access window.location.href: SecurityError: Permission denied to access property "href" on cross-origin object" as the result. The permission error comes from the fact that the content script executed with http://example.com/ window as sandbox prototype, yet the sandbox principal is still that of the extension page.

IMHO this situation is mostly equivalent to the case where the extension page would use window.open("http://example.com/") and try to access the resulting window. There is an important difference however. The way I understand the code under https://dxr.mozilla.org/mozilla-central/rev/2f5ffe4fa2153a798ed8b310a597ea92abd1b868/dom/base/nsGlobalWindowOuter.cpp#5682, calling window.postMessage() from this content script would set event.origin to http://example.com - it would be possible to fake first-party messaging without having permission to access the site.

To exploit this issue, the script would somehow have to survive long enough for the page to register event listeners. I didn't find a way to do that. For example, responses from the background page don't arrive - I guess that the sandbox is nuked before it can receive these responses. Also, while bug 1452037 allows setting window.location to a javascript URI, the payload will not execute.

Comment 1

[Kris Maglione [:kmag]]

This isn't a security issue. The sandbox is created with a window proxy as its prototype, and the scripts running in it will always have access to the new window that it points to after the window navigates. After that point, we're relying on security wrappers the same as we do any time scripts have access to cross-origin window proxies.

We should probably avoid executing the content scripts after navigation in this case, though.

Comment 2

[Rob Wu [:robwu]]

If this is fixed, replace the "TODO bug 1452045:" comment at the end of the following files with a regression test.

browser/components/extensions/test/browser/browser_ext_tabs_executeScript_bad.js
mobile/android/components/extensions/test/mochitest/test_ext_tabs_executeScript_bad.html

https://hg.mozilla.org/mozilla-central/file/dd9ba54d497c/browser/components/extensions/test/browser/browser_ext_tabs_executeScript_bad.js#l342
https://hg.mozilla.org/mozilla-central/file/dd9ba54d497c/mobile/android/components/extensions/test/mochitest/test_ext_tabs_executeScript_bad.html#l164