1657916 - (CVE-2020-35111) proxy.onRequest does not catch "view-source" URIs when used with the <all_urls> filter

Status: VERIFIED FIXED

(WebExtensions :: Request Handling, defect, P2)

Description

[Yassine Tioual]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36

Steps to reproduce:

When using FoxyProxy or Proxy SwitchyOmega (the two most downloaded proxy switcher extensions), I noticed that requests do not get proxied when using the "view-source" scheme.

Steps to reproduce:

1. Setup FoxyProxy or Proxy SwitchyOmega to proxy traffic to an external proxy (different public IP address)
2. Go to https://ipinfo.io/ip . You'll see the proxy's IP address.
3. Now go to view-source:https://ipinfo.io/ip?x=x . You'll see your network's IP address (?x=x is mainly used as a cachebuster to prevent showing the same IP address that was cached after the first request)

This was tested on FoxyProxy 7.5.1 and Proxy SwitchyOmega 2.5.20

Actual results:

This behavior discloses a user's real IP address.

This scenario can happen really often amongst web developpers and security researchers, when the source code is inspected using Ctrl+U and then later on, HTTP parameters are modified (and thus a new request using "view-source" is made) to see the effect they have on the webpage.

When inspecting FoxyProxy, I noticed that they use proxy.onRequest API (which is the recommended way since Firefox 68) to proxy requests:

(background.js lines 185 & 194)
browser.proxy.onRequest.addListener(proxyRequest, {urls: ["<all_urls>"]});

By setting a break point on the "proxyRequest" function, I noticed that this function is never called when using the "view-source" scheme. The documentation shows that <all_urls> filter does not support this scheme:

https://developer.mozilla.org/fr/docs/Mozilla/Add-ons/WebExtensions/Match_patterns

Exploitation of this behavior is pretty much unlikely, as redirecting a user to a URI with a "view-source" scheme will get blocked by the SOP. However, users can inadvertedly leak their IP address.

Expected results:

Even if (to my understanding) FoxyProxy does not support the "view-source" scheme (I plan on opening a bug request once this is resolved), the <all_urls> filter should be able to include URIs that have "view-source" as a scheme.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Kershaw Chang [:kershaw]]

I've looked this a bit.
It seems that ChannelWrapper::Matches returns false at here because the url is not matched. The final url here is view-source:https://ipinfo.io/ip?x=x. I guess the extension code or something else doesn't expect to process the url with view-source scheme.

Comment 3

[Alex Cornestean]

Hello,

I’ve managed to reproduce the issue on the latest Nightly (81.0a1/20200811091731), Beta (80.0b6/20200807195315) and Release (79.0/20200720193547) under Windows 10 Pro 64-bit and Ubuntu 16.04 LTS.

I’ve configured both proxy add-ons mentioned in the report with this server address 110.164.253.85 on port 8080. When I’ve accessed https://ipinfo.io/ip, the correct proxy address was displayed. Accessing view-source:https://ipinfo.io/ip?x=x afterwards, however, displayed the real IP address of my machine (sometimes a refresh was required for the real IP to be displayed), thus confirming the issue.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mixedpuppy, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 5

[Frederik Braun [:freddy]]

AFAIU, this is in WebRequest code, so the leak doesn't occur with typical proxy settings. The issue is solely in the APIs we provide for writing proxy-like extensions, correct? I.e., there is no leak when using "typical" proxy settings, correct?
I wonder why folks would use WebRequest when we do have a proxy API

I would call it sec-low, unless there is a way to trigger a view-source load from content. If we (or the reporter) finds a way to leak this from an evil website, I'd rate it sec-moderate.

Comment 6

[Yassine Tioual]

You are correct, the typical proxy settings are not affected by this leak.
When I inspected both extensions, they do indeed use the Proxy API and not WebRequest, so I guess this is an issue in the Proxy API.

I am still investigating how one could trigger a view-source from a controlled page. The only way I found so far is by setting the "security.view-source.reachable-from-inner-protocol" to "true" and setting an attacker-controlled URL as the src of an img tag in the page, but it requires user interaction so I don't consider this a valid case.

I'll keep you updated if I find a bypass to this.

Comment 7

[:Gijs (he/him)]

(In reply to Yassine Tioual from comment #6)

"security.view-source.reachable-from-inner-protocol" to "true"

Bah, that pref still exists? Ugh. Thanks for reminding me. I filed bug 1661672 to get rid of it.

The webrequest side of this is bug 1439163, I think?

Comment 8

[Shane Caraveo (:mixedpuppy)]

Seems like there is confusion here about proxy and webrequest. In terms of a privacy leak, this is a proxy api issue.

In terms of the actual problem, ChannelWrapper is the underlying issue that affects both of them.

Comment 9

[Shane Caraveo (:mixedpuppy)]

Attachment: Bug 1657916 allow extensions to see view-source requests

View source prefixes urls with a view-source scheme. Somewhere along
the way a request is made for the un-prefixed url but we do not intercept. This
removes the prefix for webrequest and proxy APIs prior to checking access rules
and filters, allowing the APIs to intercept those requests that the otherwise
could.

Comment 10

[Shane Caraveo (:mixedpuppy)]

Hrm, I just realized this is marked as a security issue. It really isn't anything that I think needs to be non-public.

Comment 11

[Frederik Braun [:freddy]]

We generally consider proxy bypasses that are triggered from web content in a non-webextension settings as sec-high, so I wanted to err on the side of caution.

This was under the assumption that the reporter may find a method to bypass a proxy that can be triggered from web content (in comment 5). I'd rather have this bug private and turn out less bad as we thought than public and then become worse. As per comment 6, this seems not to be the case? As a sec-low bug, you can just land the patch without any extra approval and we can make the bug public thereafter.

Comment 13

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

allow extensions to see view-source requests r=robwu
https://hg.mozilla.org/integration/autoland/rev/8fd81380d432c26a9df2ea56f9330868363dec68
https://hg.mozilla.org/mozilla-central/rev/8fd81380d432

Comment 14

[Ryan VanderMeulen [:RyanVM]]

Is this something we need to consider uplifting?

Comment 15

[Alex Cornestean]

Hello,

Verified the fix using the latest Nightly (84.0a1/20201028092421) under Windows 10 Pro 64-bit and Ubuntu 16.04 LTS.

Similar to Comment 3, I’ve configured both add-ons with this server address 103.206.105.193 on port 3629 and accessed https://ipinfo.io/ip. The correct proxy address was displayed. Accessing view-source:https://ipinfo.io/ip?x=x afterwards, also displayed the proxied address, thus confirming the fix.

Comment 16

[Ryan VanderMeulen [:RyanVM]]

Per Slack discussion, it sounds like we want to let this ride the next cycle rather than uplifting.

Comment 17

[Shane Caraveo (:mixedpuppy)]

Comment on attachment 9173508 [details]
Bug 1657916 allow extensions to see view-source requests

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: view-source requests are not caught by proxies in extensions, so this is a touch of a leak. We've lived with it for a long time, but since esr is long lived, it would be good to uplift it. We otherwise intend this to just ride the train on normal releases.
• User impact if declined: view-source requests may not be proxied
• Fix Landed on Version: 84
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a small change with a good set of tests on it.
• String or UUID changes made by this patch:

Comment 18

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9173508 [details]
Bug 1657916 allow extensions to see view-source requests

Approved for 78.6esr.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/aa4b96101620

Comment 22

[Alex Cornestean]

Hello,

Verified the fix using the latest ESR (78.6.0esr/20201207224150) under Windows 10 Pro 64-bit and Ubuntu 16.04 LTS.

I’ve configured both add-ons with this server address 82.200.233.4 on port 3128 and accessed https://ipinfo.io/ip. The correct proxy address was displayed. Accessing view-source:https://ipinfo.io/ip?x=x afterwards, also displayed the proxied address, thus confirming the fix.

Comment 23

[Tom Ritter [:tjr] (OOTO until 4/30 at least)]

Attachment: advisory.txt