Closed Bug 1437325 (CVE-2018-5166) Opened 2 years ago Closed 2 years ago

Web extension - Web Request host permission bypass using filterReponseData

Categories

(WebExtensions :: Request Handling, defect, P2)

58 Branch
defect

Tracking

(firefox-esr52 wontfix, firefox58 wontfix, firefox59 wontfix, firefox60 fixed)

VERIFIED FIXED
mozilla60
Tracking Status
firefox-esr52 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- fixed

People

(Reporter: francois.lajeunesse.robert, Assigned: kmag)

Details

(Keywords: sec-moderate, Whiteboard: [adv-main60+])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
Build ID: 20180206200532

Steps to reproduce:

By leveraging the request redirection and filterReponseData, one can bypass the host permission to access content returned by an arbitrary host.


Actual results:

The attachment is a POC extension that have the webRequest, webRequestBlocking and http://localhost permission that upon loading will :
1- Open a new tabs to http://localhost
2- Redirect the request toward https://bugzilla.mozilla.org/user_profile
3- Output the content of https://bugzilla.mozilla.org/user_profile in the console
4- Close the tab


Expected results:

filterResponseData should be allowed only if the extension has the host permission for the fetched resource.
Moving over to webextensions.
Group: firefox-core-security → toolkit-core-security
Component: Untriaged → WebExtensions: Request Handling
Flags: needinfo?(ddurst)
Product: Firefox → Toolkit
Assignee: nobody → mixedpuppy
Status: UNCONFIRMED → NEW
Ever confirmed: true
The issue here is that StreamFilter is not disconnected upon a redirect.  

The filter remains connected and receives data on the redirected channel.  In a poorly written extension, this could result in multiple filters receiving the data.  A short test I did, based on the attached extension, initiated a tab to http://allizom.org, which redirected -> https://allizom.org -> https://bugzilla.mozilla.org and I received 3 dumps of the page content for bugzilla.  Note that for that to happen I changed to all_urls.

I'm really not certain of the sec severity here, if I were after the page content of a site I'd just request all_urls to begin with since I wouldn't have to depend on a bug and IMO that permission would likely bypass user scrutiny.
Kris, have any thoughts on a direction for a fix in StreamFilter?
Flags: needinfo?(kmaglione+bmo)
Flags: needinfo?(ddurst)
Given my thoughts on the severity (comment 2) I'm only putting this at p2.
Priority: -- → P2
For CSP we had to hook redirects and re-evaluate the policy permissions at each redirect. I think your filter will have to do the same and kill the stream when you bounce to an unallowed host.
Keywords: sec-moderate
I'm inclined towards always disconnecting StreamFilter on a redirect.
This will be fixed by bug 1444539.
Flags: needinfo?(kmaglione+bmo)
Marius, can you please confirm that bug 1444539 fixes this issue as described in comment 0? Please do not comment in that bug about its relationship to this one.

Thanks
Flags: needinfo?(marius.santa)
Attached image host permision.gif
I was unable to reproduce the bug on Firefox 60.0a1 (20180210220139).
I have attached the results I get when testing on the latest nightly Firefox 61.0a1 (20180313100127).
I just loaded the extension temporary and looked in the console for the output, tried this while logged in and out from https://bugzilla.mozilla.org.
Flags: needinfo?(marius.santa)
Assignee: mixedpuppy → kmaglione+bmo
Thanks.
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Group: toolkit-core-security → core-security-release
Whiteboard: [adv-main60+]
Alias: CVE-2018-5166
Product: Toolkit → WebExtensions
Group: core-security-release
You need to log in before you can comment on or make changes to this bug.