1618271 - DNS leaks about `browser.dns` API

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[hxxtom]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0

Steps to reproduce:

The origin thread please see "uBlock Origin v1.25.0 new feature cause DNS leaks.": https://github.com/uBlockOrigin/uBlock-issues/issues/911

Here is summary about it:

The new feature on uBlock Origin use "browser.dns" API to block 1st-party tracking. But it cause DNS leaks.

Reproduce steps:

1. Install the uBlock origin v1.25.0.
2. Setting the socks5 proxy for Firefox. (If you don't have one socks5 proxy, you can download the Torbroswer from Tor project website. TBB will listen on 127.0.0.1:9150)
3. Using the DNS leaks test service like:

• https://ipleak.net/
• https://dnsleaktest.com/
• http://whatismydnsresolver.com/

Actual results:

You can see your location is exposed. And use tcpdump udp, you can find that UDP DNS traffic was sent. It will cause a privacy problem to users who use a socks proxy.

Expected results:

Perhaps the browser.dns API shouldn't process DNS query when users set a socks proxy on Firefox.

Comment 1

[Shane Caraveo (:mixedpuppy)]

Honza, IIUC from reading a few bugs, nsIDNSService will bypass socks. This is what we use in the dns api. From bug 1470411 there doesn't seem to be a clear path to addressing this. Is that correct?

Comment 2

[Honza Bambas (:mayhemer)]

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)

Honza, IIUC from reading a few bugs, nsIDNSService will bypass socks. This is what we use in the dns api. From bug 1470411 there doesn't seem to be a clear path to addressing this. Is that correct?

The Necko DNS service (nsIDNSService) doesn't know anything about proxy settings. As I understand, the request here is that if there is a socks proxy enabled and is also set to resolve hosts on its own, we should make browser.dns just fail? AFAIK, there is now way to use the proxy to only resolve hosts (as a DNS resolver of sort) - a.k.a to forward browser.dns to the proxy.

If browser.dns failing is the possible fix, then the API implementation has to check for the proxy settings. It would be network.proxy.type == 1, network.proxy.socks is non-empty and network.proxy.socks_remote_dns == true.

Comment 3

[hxxtom]

(In reply to Honza Bambas (:mayhemer) from comment #2)

[...] As I understand, the request here is that if there is a socks proxy enabled and is also set to resolve hosts on its own, we should make browser.dns just fail? AFAIK, there is now way to use the proxy to only resolve hosts (as a DNS resolver of sort) - a.k.a to forward browser.dns to the proxy.

If browser.dns failing is the possible fix, then the API implementation has to check for the proxy settings. It would be network.proxy.type == 1, network.proxy.socks is non-empty and network.proxy.socks_remote_dns == true.

I don't know if socks5 support DNS forwarding. I thought it doesn't support. (Or it just because Tor socks5 doesn't support UDP traffic?). So I request here make that API fail.

If DNS traffic can be forward to the proxy, "forward browser.dns to the proxy" sounds a better solution. And maybe it should change to a better title. BTY, I think Honza's comment on bug 1546924 look nice.

Comment 4

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

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

For more information, please visit auto_nag documentation.

Comment 5

[hxxtom]

Some update from the original thread on uBlock-issues:

gorhill add proxy-detecting code to uBlock Origin (by checking if proxyInfo property of webRequest.onHeadersReceived listener is set), so it won't use browser.dns API when a request passes the proxy. The proxy-detecting code may be removed when this Firefox issue is fixed.

Comment 6

[Tomislav Jovanovic :zombie]

Hey Tom, can you look into this, is it something we need to handle on the level of Firefox/Tor or not? Or can you forward to someone else from the Tor project?

Comment 7

[Matthew Finkel [:sysrqb]]

(In reply to Honza Bambas (:mayhemer) from comment #2)

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)

Honza, IIUC from reading a few bugs, nsIDNSService will bypass socks. This is what we use in the dns api. From bug 1470411 there doesn't seem to be a clear path to addressing this. Is that correct?

The Necko DNS service (nsIDNSService) doesn't know anything about proxy settings. As I understand, the request here is that if there is a socks proxy enabled and is also set to resolve hosts on its own, we should make browser.dns just fail? AFAIK, there is now way to use the proxy to only resolve hosts (as a DNS resolver of sort) - a.k.a to forward browser.dns to the proxy.

Tor supports this, but it is non-standard.

If browser.dns failing is the possible fix, then the API implementation has to check for the proxy settings. It would be network.proxy.type == 1, network.proxy.socks is non-empty and network.proxy.socks_remote_dns == true.

This would be ideal in this scenario.

Tor Browser has a patch that mitigates this, but it'd be great to have something like this in Firefox. https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-68.7.0esr-9.5-1&id=680a234d549e63cd69e4429af183cab19caa2977

It looks like the defense-in-depth protected Tor Browser, here.

Comment 8

[Shane Caraveo (:mixedpuppy)]

Honza, is the patch in comment 7 something we'd consider adopting? ISTM that would be in-depth whereas doing it in the extension api only protects against requests by extensions.

Comment 9

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

FWIW; we have the --enable-proxy-bypass-protection flag which can be used to conditionally compile this type of code just for Tor...

Comment 10

[Honza Bambas (:mayhemer)]

Valentin, as our DNS master, what do you think about this bug?

Comment 11

[Valentin Gosu [:valentin] (he/him)]

(In reply to Matthew Finkel [:sysrqb] from comment #7)

(In reply to Honza Bambas (:mayhemer) from comment #2)

(In reply to Shane Caraveo (:mixedpuppy) from comment #1)

Honza, IIUC from reading a few bugs, nsIDNSService will bypass socks. This is what we use in the dns api. From bug 1470411 there doesn't seem to be a clear path to addressing this. Is that correct?

The Necko DNS service (nsIDNSService) doesn't know anything about proxy settings. As I understand, the request here is that if there is a socks proxy enabled and is also set to resolve hosts on its own, we should make browser.dns just fail? AFAIK, there is now way to use the proxy to only resolve hosts (as a DNS resolver of sort) - a.k.a to forward browser.dns to the proxy.

Tor supports this, but it is non-standard.

Is this documented anywhere? I'm wondering if we could fallback to this so we don't just fail requests when a proxy is set.

Tor Browser has a patch that mitigates this, but it'd be great to have something like this in Firefox. https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-68.7.0esr-9.5-1&id=680a234d549e63cd69e4429af183cab19caa2977

It looks like the defense-in-depth protected Tor Browser, here.

This is great. I'll try to work it into a patch. It's probably easier than to hack our way around this.

Comment 12

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1618271 - Move network.proxy.type to StaticPrefList.yaml r=mayhemer

Comment 13

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 1618271 - Fail DNS requests when proxy is in use r=mayhemer

Depends on D80888

Comment 14

[Georg Koppen]

It seems the proposed patch is planned to do something similar than the fix in bug 1636411. I wonder whether one could not reuse that work and just, say, flip network.dns.disabled if a socks proxy with remote resolution is used and flip it back if not. I think I am confused why we essentially need two different approaches for reaching the same goal.

Comment 15

[Valentin Gosu [:valentin] (he/him)]

(In reply to Georg Koppen from comment #14)

It seems the proposed patch is planned to do something similar than the fix in bug 1636411. I wonder whether one could not reuse that work and just, say, flip network.dns.disabled if a socks proxy with remote resolution is used and flip it back if not. I think I am confused why we essentially need two different approaches for reaching the same goal.

Flipping a pref in response to other prefs changing seems risky to me. (For example what if we crash before we flip the disabled pref).
Also, we might not disable DNS resolution completely when a proxy is in use. We may want to check is ProxyService::CanUse.

Comment 16

[Shane Caraveo (:mixedpuppy)]

We probably need some test in the extension browser api to verify the behavior at that layer. If it doesn't get done here, please file a followup bug.

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f900ff75a000
Move network.proxy.type to StaticPrefList.yaml r=mayhemer,necko-reviewers
https://hg.mozilla.org/integration/autoland/rev/68dc9e49b744
Fail DNS requests when proxy is in use r=mayhemer,necko-reviewers

Comment 18

[Razvan Maries]

https://hg.mozilla.org/mozilla-central/rev/f900ff75a000
https://hg.mozilla.org/mozilla-central/rev/68dc9e49b744

Comment 19

[Bogdan Maris, Desktop QA]

Reproduced the DNS leak using a free socket5 proxy on Firefox 73.0 with uBlock Origin v1.25.0.
Verified that there is no leak using the following setup:

• All platforms (Windows 10 64bit, Ubuntu 18.04 64bit, macOS 10.15.6)
• Firefox 80.0 RC
• uBlock Origin v1.25.0, v1.29.0

Comment 20

[hxxtom]

The leak still exists, using the following setup:

• Debian 11.4 64bit
• Firefox 91.13.0 (esr), 107.0a1 (2022-09-20, nightly)
• uBlock Origin v1.44.4

Comment 21

[Valentin Gosu [:valentin] (he/him)]

Since this was verified as fixed, possibly we have are regression.
Could you file a new bug for this work?
If possible, could you use mozregression to find out when this started failing? Thanks!

Comment 22

[hxxtom]

Sorry, I didn't set pref network.proxy.socks_remote_dns is true leading me can reproduce on the nightly build. When network.proxy.socks_remote_dns = true, there is no leak, while network.proxy.socks_remote_dns = false, the leak will happen.

But I also found use an extension to manage proxy and pref network.proxy.socks_remote_dns = true will not prevent these leaks, which is my ESR build's use case. The pref network.proxy.socks_remote_dns will work when network.proxy.type = 1, and network.proxy.type = 0/2/4/5 doesn't work with it. Using an extension to manage the proxy is necessary to set it as 1. I think I will file another bug to report this.

Comment 23

[hxxtom]

Typo: Using an extension to manage the proxy is not necessary to set it as 1. (I didn't find where I can edit the comment.)