Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

uBlock Origin v1.25.0 new feature cause DNS leaks. #911

Closed
6 of 8 tasks
tomac4t opened this issue Feb 26, 2020 · 22 comments
Closed
6 of 8 tasks

uBlock Origin v1.25.0 new feature cause DNS leaks. #911

tomac4t opened this issue Feb 26, 2020 · 22 comments
Labels
external issue involving an external factor Firefox specific to Firefox fixed issue has been addressed

Comments

@tomac4t
Copy link

tomac4t commented Feb 26, 2020

Prerequisites

  • I verified that this is not a filter issue
  • This is not a support issue or a question
  • I performed a cursory search of the issue tracker to avoid opening a duplicate issue
    • Your issue may already be reported.
  • I tried to reproduce the issue when...
    • uBlock Origin is the only extension
    • uBlock Origin with default lists/settings
    • using a new, unmodified browser profile
  • I am running the latest version of uBlock Origin
  • I checked the documentation to understand that the issue I report is not a normal behavior

Description

Hello there, I notice that uBlock Origin v1.25.0 have a new way to block 1st-party tracking. This problem is related to #780.

Let me explain a little bit of background first. To protect my privacy, I use a socks5 proxy to surfing the internet. I setting a manual proxy configuration on my Firefox and check the box "Proxy DNS when using SOCKS v5". It shouldn't have any UDP DNS traffic, but it happened (sudo tcpdump udp can confirm it.).

It makes me pretty annoying that It exposed my real location and the ISP will know what I browse. I wonder if it's a bug of Debian Firefox ESR. So I download the latest Firefox stable, the problem was gone. Then I switch to old Firefox profile, the problem back again. So I suspect some extensions may cause. Finally, I found it is uBlock Origin cause UDP DNS traffic. I remember that it requires IP/Hostname permission after yesterday upgrade.

A specific URL where the issue occurs

No specific URL.

Steps to Reproduce

  1. It required a socks5 proxy. Torbroswer provides the free socks5 proxy. The first thing is to download the TBB from Torproject website.
  2. Setting the socks5 proxy for Firefox. (TBB is listen on 127.0.0.1:9150)
  3. Using the DNS leaks test service like:

Expected behavior:

It shouldn't be any UDP DNS traffic if you setting the socks5 proxy on Firefox.

Actual behavior:

UDP DNS traffic happened when I setting the socks5 proxy on Firefox, even I check the box "Proxy DNS when using SOCKS v5".

Your environment

  • uBlock Origin version: uBlock Origin v1.25.0 from AMO
  • Browser Name and version: Firefox 73.0.1 (64-bit)
  • Operating System and version: GNU/Linux Debian
@tomac4t
Copy link
Author

tomac4t commented Feb 26, 2020

I think uBlock Origin shouldn't check the DNS CNAME record when users setting their proxy configure on Firefox.

@gorhill
Copy link
Member

gorhill commented Feb 26, 2020

uBO just makes use of the browser.dns API. If you think the API is doing something wrong that disregard OS- or Firefox-side settings which you think should not be disregarded, you will have to file an issue with Firefox.

You can disable uBO's canonical name-uncloaking from advanced settings if you do not like the feature.

@gorhill gorhill closed this as completed Feb 26, 2020
@gorhill gorhill added the external issue involving an external factor label Feb 26, 2020
@uBlock-user uBlock-user added the invalid not a uBlock issue label Feb 26, 2020
@tomac4t
Copy link
Author

tomac4t commented Feb 26, 2020

Okay, It's nothing could do with Firefox either, because socks5 doesn't support DNS forwarding (I'm not pretty sure). So Firefox will use local DNS. The only thing could I do is enable DoH feature and set network.trr.mode=3. Maybe uBlock should write a document about it. It is a real side effect on the new feature (to some users). @gorhill

Edited: I open a thread on bugzilla: https://bugzilla.mozilla.org/show_bug.cgi?id=1618271

@lilydjwg
Copy link

Recently I notice DNS leaks too. I looked everywhere and finally found uBlock Origin. Even this is unavoidable or broken because the browser API I think uBlock Origin should make people aware of this issue.

BTW why isn't uBlock Origin using the offline option like Flagfox?

@gorhill
Copy link
Member

gorhill commented Mar 22, 2020

@lilydjwg Is your setup similar to OP, i.e. using a socks5 proxy?

@lilydjwg
Copy link

lilydjwg commented Mar 22, 2020

@gorhill I use a PAC file to proxy part of my requests, and some of them are proxied to a socks5 proxy. Flagfox will show that it doesn't have the DNS information on proxied websites.

I saw some DNS requests for domains that should have gone to the proxy and after some observation I found uBlock Origin was doing this. Setting cnameUncloak: false makes those unintended DNS requests go away.

@gorhill
Copy link
Member

gorhill commented Mar 22, 2020

@lilydjwg From your profile, it seems you would be able to use the debugger to step into uBO's code?

If so, I would be curious to find out whether the proxyInfo property is set when uBO's onHeadersReceived listener is called.

My thinking is that uBO could maybe avoid using browser.dns.resolve() if it is able to detect that the network requests are proxied -- at least until 1618271 is resolved.

@lilydjwg
Copy link

lilydjwg commented Mar 22, 2020

@gorhill Yes it's set and proxyDNS is true.

Edit: I mean it's set when the request is proxied (all properties seem ready). It's null if not proxied.

@gorhill gorhill reopened this Mar 22, 2020
@uBlock-user uBlock-user removed the invalid not a uBlock issue label Mar 22, 2020
@tomac4t
Copy link
Author

tomac4t commented Mar 22, 2020

BTW why isn't uBlock Origin using the offline option like Flagfox? [...] Flagfox will show that it doesn't have the DNS information on proxied websites.

I am also a user of Flagfox, notice that it doesn't cause DNS leaks. Reading the code finding that it uses offline flag. After I try this idea, I don't think it could work in this case, because it won't have any DNS CNAME record cache before uBlock request (unlike DNS A/AAAA record in Flagfox case).

@gorhill
Copy link
Member

gorhill commented Mar 22, 2020

What Flagfox does is not applicable to uBO -- uBO uses the API in a blocking manner, i.e. the dns.resolve() API is used while the network request is held back until an answer arrive. In Flagfox, the dns.resolve() is used to observe only, not in a blocking manner.

gorhill added a commit to gorhill/uBlock that referenced this issue Mar 22, 2020
Related issue:
- uBlockOrigin/uBlock-issues#911

Since cname-uncloaking is available only on Firefox
at the moment, the fix is relevant only to Firefox.

By default uBO will no longer cname-uncloak when it
detects that network requests are being being proxied.

This default behavior can be overriden by setting the
new advanced setting `cnameUncloakProxied` to `true`.
The new setting default to `false`, i.e. cname-uncloaking
is disabled when uBO detects that a proxy is in use.

This new advanced setting may disappear once the
following Firefox issue is fixed:
- https://bugzilla.mozilla.org/show_bug.cgi?id=1618271
@gorhill
Copy link
Member

gorhill commented Mar 22, 2020

In the latest dev build, 1.25.3b7, uBO will automatically disable cname-uncloaking when it detects that requests are proxied. To find out if this work as intended, you will of course need to put back cnameUncloak to its default value of true.

Feedback appreciated.

@tomac4t
Copy link
Author

tomac4t commented Mar 23, 2020

I still have the problem in uBlock Origin v1.25.3b7.

Settings

  • Setup a socks5 proxy on Firefox 74.0.
  • network.proxy.socks_remote_dns=true in about:config (same proxyDNS: true as @lilydjwg)
  • network.trr.mode=0 in about:config
  • cnameUncloak: true, cnameUncloakProxied: false in uBO advanced settings

What I see

I open the https://ipleak.net/ and doing some test. Using tcpdump to capture UDP DNS traffic, I still see something like follow (tomacat is my machine's hostname):

$ sudo tcpdump udp port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp3s0, link-type EN10MB (Ethernet), capture size 262144 bytes
12:50:07.166089 IP tomacat.37560 > _gateway.domain: 11448+ A? nwv5dyztu6o1o7xg5yp8nmr0dnqyf48qw32pzslo.ipleak.net. (69)
12:50:07.166111 IP tomacat.37560 > _gateway.domain: 23238+ AAAA? nwv5dyztu6o1o7xg5yp8nmr0dnqyf48qw32pzslo.ipleak.net. (69)
12:50:07.167239 IP tomacat.39124 > _gateway.domain: 46747+ A? g15hezrsl41pg2n3xice1chrvkbpwzr8k2fo68k1.ipleak.net. (69)
12:50:07.167252 IP tomacat.39124 > _gateway.domain: 35495+ AAAA? g15hezrsl41pg2n3xice1chrvkbpwzr8k2fo68k1.ipleak.net. (69)
12:50:07.168623 IP tomacat.53883 > _gateway.domain: 7761+ A? soycqomnr363xhy64o4vgskbbhszu1aowji5ekeb.ipleak.net. (69)
12:50:07.168638 IP tomacat.53883 > _gateway.domain: 1628+ AAAA? soycqomnr363xhy64o4vgskbbhszu1aowji5ekeb.ipleak.net. (69)
12:50:07.571706 IP _gateway.domain > tomacat.37560: 11448 1/0/0 A 95.85.16.212 (85)
12:50:07.571720 IP _gateway.domain > tomacat.53883: 7761 1/0/0 A 95.85.16.212 (85)
12:50:07.571728 IP _gateway.domain > tomacat.43213: 61608 1/0/0 A 95.85.16.212 (85)
12:50:07.571735 IP _gateway.domain > tomacat.43213: 3763 1/0/0 AAAA 2a03:b0c0:0:1010::509:d001 (97)
12:50:07.572258 IP tomacat.53185 > _gateway.domain: 35947+ A? zaqyly2w67351l9ks4dq52wa3eggjh41xejzn663.ipleak.net. (69)
12:50:07.572272 IP tomacat.53185 > _gateway.domain: 52853+ AAAA? zaqyly2w67351l9ks4dq52wa3eggjh41xejzn663.ipleak.net. (69)
[...]

Then I setting cnameUncloak: false, the problem gone again. (Test on both my Firefox old profile and new profile.)

@lilydjwg
Copy link

I'm afraid that it didn't work. I still observe the same DNS leak.

@uBlock-user uBlock-user added the Firefox specific to Firefox label Mar 23, 2020
@gorhill
Copy link
Member

gorhill commented Mar 23, 2020

Setup a socks5 proxy on Firefox 74.0.

I don't have a proxy provider. Is there a way for me to test this on my side?

@tomac4t
Copy link
Author

tomac4t commented Mar 23, 2020

I don't have a proxy provider. Is there a way for me to test this on my side?

Tor browser provide one, it is listen on 127.0.0.1:9150.

Steps

  • Start Tor browser and make it connect to Tor network. (shouldn't be hard.)
  • Start the Firefox as following prefs:
user_pref("network.proxy.type", 1);
user_pref("network.proxy.socks", "127.0.0.1");
user_pref("network.proxy.socks_port", 9150);
user_pref("network.proxy.socks_remote_dns", true);

(Edited: I can't reproduce on Tor Browser itself, I think TBB may have some security hardening on this side.)

@gorhill
Copy link
Member

gorhill commented Mar 23, 2020

@tomac4t Great, this works for testing purpose -- I already had the Tor browser installed. So anyways now that I could test the code path I see that there is a typo in the code. I will publish a fix asap.

gorhill added a commit to gorhill/uBlock that referenced this issue Mar 23, 2020
gorhill added a commit to gorhill/uBlock that referenced this issue Mar 23, 2020
Related commit:
- uBlockOrigin/uBlock-issues#911

The motivation is to avoid executing code which is
unnecessary on platforms not supporting the browser.dns
API.
@tomac4t
Copy link
Author

tomac4t commented Mar 24, 2020

03/24/2020: After trying uBlock Origin v1.25.3b8, I didn't observe UDP DNS traffic anymore when the proxy is set up on Firefox. I observe UDP DNS from my firefox again (old profile with Firefox 74), after restarting the firefox then the situation disappear. If there is further information, I will append here. I still can't reproduce it on new profile of Firefox Developer (75.0b7) with lastest uBO (fe0c2c). Everything works great.

I also test the case when setting a proxy with an add-on like SwitchyOmega. PAC (Automatic proxy configuration, which @lilydjwg comment above) case I didn't test, because I don't familiar with it. But I think it also could work.

03/25/2020: Firefox 74.0 with uBlock Origin v1.25.3b9 works fine.

@lilydjwg
Copy link

I don't see leaked DNS queries now but I'm still monitoring.

@uBlock-user uBlock-user added the fixed issue has been addressed label Mar 25, 2020
@nobura
Copy link

nobura commented Mar 30, 2020

its still leak with latest ublock origin 1.25.3rc0, when check use https://www.expressvpn.com/dns-leak-test

Steps to Reproduce
install dan start browsec https://addons.mozilla.org/en-US/firefox/addon/browsec/ or hoxx vpn https://addons.mozilla.org/en-US/firefox/addon/hoxx-vpn-proxy/

use DNS leaks test site
https://www.expressvpn.com/dns-leak-test

but when check use https://dnsleaktest.com/, doesn't leak

@ThurahT
Copy link

ThurahT commented Apr 9, 2020

FF 68.6.1esr and uBO 1.26.0 works as intended. Cname lookup is disabled when browser is proxied. And enabled when not.

Also I find that http://browserleaks.com/dns gives the most correct results. It resolves 100 randomly generated domain names asynchronously, 50 with A record (IPv4-only) and 50 with both A and AAAA records. And does so really fast compared to the other tests.

Orbot on android with FF 68.6.0esr and uBO 1.26.0 does some magic with the "vpn" feature and uBO doesn't detect browser is proxied and Cname lookup works. That with no dns leakage.

Before uBO 1.26.0 I made a script that cleared /etc/resolv.conf and Cname lookup stopped working on uBO 1.25.2, further prooving the FF bug.

I really hope FF devs fix the bug since Cname lookup is a cool feature in uBO. When uMA gets it I hope it also have the fix from uBO to disable it on proxied browsers until FF is fixed.

Thank you gorhill for the awesome work with both extensions.

@uBlock-user
Copy link
Contributor

uBlock-user commented Apr 9, 2020

When uMA gets it I hope it also have the fix from uBO to disable it on proxied browsers until FF is fixed.

CNAME uncloaking is already present in the dev build of uMatrix, the workaround added in uBO however is not, so you might reproduce it with uMatrix dev build.

@ghost

This comment has been minimized.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
external issue involving an external factor Firefox specific to Firefox fixed issue has been addressed
Projects
None yet
Development

No branches or pull requests

6 participants