1470411 - DNS search domain bypassing SOCKS proxy

Status: NEW

(Core :: Networking: Proxy, defect, P3)

Description

[Alex Catarineu]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0
Build ID: 20180607190419

Steps to reproduce:

Make sure there is a DNS search domain defined at system level (e.g. in Linux add line 'search bar.net' to /etc/resolve.conf if needed). Set a socks5 proxy in Firefox and enable proxy DNS. In the url bar, type a simple word without spaces that does not look like a domain (e.g: foo). Unfocus the url bar (for example by clicking somewhere in the page). Focus again the urlbar: now there still should be the query (e.g. foo) but without any open results. Press enter.


Actual results:

There are DNS requests being done outside the proxy with the DNS search domain defined in the system, in the given example: 'foo.bar.net'.


Expected results:

All DNS should be proxied through the SOCKS proxy defined in the preferences.

This is the case with the usual path, where user does not unfocus the urlbar and instead presses enter when there are open results. Apparently, this is handled in 'browser/base/content/urlbarBindings.xml:handleCommand', and the common path seems to be when the url/result has the prefix 'moz-action:...'. With the steps to reproduce above, it hits a different path instead and ends up calling 'openUILinkIn(query)', query being in the example 'foo'. This seems to be causing the DNS bypass, but did not investigate further.

Comment 1

[Daniel Bodea [:danibodea]]

I could not reproduce this issue on my Ubuntu 16.04. I am setting the component to (Core) Networking: DNS and let te developers decide whether this is a valid issue or not.

Comment 2

[Michal Novotny [:michal]]

The request comes from predictor:

#0  0x00007f1c8728ddd2 in nsDNSService::AsyncResolveNative(nsTSubstring<char> const&, unsigned int, nsIDNSListener*, nsIEventTarget*, mozilla::OriginAttributes const&, nsICancelable**) (this=0x7f1c9ec61a70, aHostname=..., flags=20, aListener=0x7f1c541929a0, target_=0x0, aOriginAttributes=..., result=0x7ffff214a7e8)
    at /mnt/work/opt/moz/hg-inbound-3/netwerk/dns/nsDNSService2.cpp:834
#1  0x00007f1c87116302 in mozilla::net::Predictor::RunPredictions(nsIURI*, mozilla::OriginAttributes const&, nsINetworkPredictorVerifier*) (this=0x7f1c5cd7b100, referrer=0x7f1c541a6400, originAttributes=..., verifier=0x0)
    at /mnt/work/opt/moz/hg-inbound-3/netwerk/base/Predictor.cpp:1420
#2  0x00007f1c871157e7 in mozilla::net::Predictor::PredictForPageload(nsICacheEntry*, nsIURI*, unsigned char, bool, nsINetworkPredictorVerifier*) (this=0x7f1c5cd7b100, entry=0x7f1c6858c3d0, targetURI=0x7f1c541a6400, stackCount=0 '\000', fullUri=false, verifier=0x0) at /mnt/work/opt/moz/hg-inbound-3/netwerk/base/Predictor.cpp:971
#3  0x00007f1c871111f5 in mozilla::net::Predictor::PredictInternal(unsigned int, nsICacheEntry*, bool, bool, nsIURI*, nsINetworkPredictorVerifier*, unsigned char) (this=0x7f1c5cd7b100, reason=1, entry=0x7f1c6858c3d0, isNew=false, fullUri=false, targetURI=0x7f1c541a6400, verifier=0x0, stackCount=0 '\000') at /mnt/work/opt/moz/hg-inbound-3/netwerk/base/Predictor.cpp:861
#4  0x00007f1c87110d65 in mozilla::net::Predictor::Action::OnCacheEntryAvailable(nsICacheEntry*, bool, nsIApplicationCache*, nsresult) (this=0x7f1c5302ace0, entry=0x7f1c6858c3d0, isNew=false, appCache=0x0, result=nsresult::NS_OK)
    at /mnt/work/opt/moz/hg-inbound-3/netwerk/base/Predictor.cpp:233
#5  0x00007f1c875bd9bb in mozilla::net::CacheEntry::InvokeAvailableCallback(mozilla::net::CacheEntry::Callback const&) (this=0x7f1c53080700, aCallback=...) at /mnt/work/opt/moz/hg-inbound-3/netwerk/cache2/CacheEntry.cpp:891
#6  0x00007f1c876228db in mozilla::net::CacheEntry::AvailableCallbackRunnable::Run() (this=0x7f1c5302aec0)
    at /mnt/work/opt/moz/hg-inbound-3/netwerk/cache2/CacheEntry.h:234
#7  0x00007f1c87026fa5 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7f1c9ec4ebb0, aMayWait=false, aResult=0x7ffff214b76e)
    at /mnt/work/opt/moz/hg-inbound-3/xpcom/threads/nsThread.cpp:1051
#8  0x00007f1c87029cdc in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7f1c9ec4ebb0, aMayWait=false)
    at /mnt/work/opt/moz/hg-inbound-3/xpcom/threads/nsThreadUtils.cpp:519

Comment 3

[Michal Novotny [:michal]]

Ignore comment #2. Something went wrong with rr and the asyncResolve call which leaks the request comes in fact from https://searchfox.org/mozilla-central/rev/403038737ba75af3842ba6b43b6e2fb47eb06609/browser/base/content/browser.js#929

Comment 4

[Ethan Tseng [:ethan]]

Gary, this bug seems to be a good fit for you. Could you take a look to see if you can take it?

Comment 5

[Gary Chen [:xeonchen]]

(In reply to Ethan Tseng [:ethan] from comment #4)
> Gary, this bug seems to be a good fit for you. Could you take a look to see
> if you can take it?

I'll append this to my queue, please let me know if this needs higher priority.

Comment 6

[Gary Chen [:xeonchen]]

Attachment: Bug 1470411 - Disable DNS prefetch when using any kind of proxy

Comment 7

[Gary Chen [:xeonchen]]

Not sure if I can correctly reproduce this, I do see some leaked DNS resolutions to default search engine, but not to foo.bar.net.
My patch might fix the scenario I saw, but I can't 100% sure this fixes the issue reported here.

So, Alex, if you don't mind could you please help to check this patch?
You can download either from the test build [1] or wait until this is landed to the Nightly channel. Thanks!

[1] https://queue.taskcluster.net/v1/task/ByKttRF_QGqYBigIYSSJZg/runs/0/artifacts/public/build/target.tar.bz2

Comment 8

[Alex Catarineu]

I still can reproduce with that test build. But I actually don't see any leaked DNS resolutions to the default search engine, so perhaps you didn't check the "Proxy DNS when using SOCKS v5"?

Let me write down the concrete steps I'm following again (Linux):

1. Edit /etc/resolv.conf (made a typo in the first message) and make sure there is a line with 'search X', for example 'search bar.net'. This is my /etc/resolv.conf content after changes:

nameserver 127.0.0.53
search bar.net

2. Run 'sudo tcpdump -i eth0 udp port 53' to see DNS requests.

3. Run firefox with a new profile.

4. Go to about:preferences, Network Settings and select "Manual proxy configuration", set SOCKS Host to 127.0.0.1 and port to 9050 (assuming Tor client is running). Select 'Proxy DNS when using SOCKS v5'. This sets the following browser prefs:

network.proxy.socks = 127.0.0.1
network.proxy.socks_port = 9050
network.proxy.socks_remote_dns = true
network.proxy.type = 1

5. Type some query in the urlbar (simple word without spaces), e.g. 'myquery'. Without hitting enter, click somewhere in the page to make the urlbar lose focus while still keeping 'myquery'. Click the urlbar to focus it again, and hit enter. It goes to the default search engine (without any DNS requests to that), but tcpdump shows:

11:49:48.394590 IP user.41913 > router.local.domain: 54368+ [1au] A? myquery.bar.net. (44)
11:49:48.394730 IP user.58532 > router.local.domain: 13939+ [1au] AAAA? myquery.bar.net. (44)
11:49:48.468661 IP router.local.domain > user.58532: 13939 NXDomain 0/1/1 (112)
11:49:48.468839 IP user.58532 > router.local.domain: 13939+ AAAA? myquery.bar.net. (33)
11:49:48.469127 IP router.local.domain > user.58532: 13939 NXDomain 0/1/0 (101)
11:49:48.487711 IP router.local.domain > user.41913: 54368 NXDomain 0/1/1 (112)

Comment 9

[Gary Chen [:xeonchen]]

The problem here is that a SOCKS server doesn't have an ability to do real DNS resolution, instead we just pass the name and the SOCKS server will figure out how to reach to the destination. So I wouldn't say the it is a DNS server, nor we know the resolution result after every connection.

This is indeed a DNS leakage issue, and unfortunately we don't have a perfect solution here. (Or we do, but in another approach, such as DoH? I'm not sure...)

I'd say some users might want to completely disallow any DNS resolution for security reasons, like Tor Browser or the reporter in this bug, and others might want have full DNS features such as DNS prefetch. And here comes another issue: what if the host name of the SOCKS server needs DNS resolution?

IMHO we could probably add a new pref to let users decide the their preference behavior. But neither of them really solve the issue.

Daniel, do you have any idea?

Comment 10

[Daniel Stenberg [:bagder]]

Alex, when you run your test, do you have the SOCKS proxy running on localhost as well? If so, how do you tell which client that is asking the DNS for the name?

Firefox should indeed pass on the name to the proxy in this setup and not resolve the name by itself, as the proxy will do it for us and Firefox shouldn't even try.

I did a slightly different experience and instead decided to log Firefox's resolver activity and I cannot reproduce this problem:

1. setup a local SOCKS5 proxy ("ssh -D 8080 remotehost" is an easy way and it makes the DNS resolves get done from another host)

2. "MOZ_LOG=nsHostResolver:5 ./mach run"

3. tell Firefox to use localhost:8080 and proxy DNS

Now, if I go to a random site or enter a random word in the address bar I do not seem being resolved by Firefox. It will resolve localhost all right.

(I can see Firefox still resolve "mozilla.org" for me, which looks like a DNS leak bug but not as described here.)

Comment 11

[Gary Chen [:xeonchen]]

(In reply to Daniel Stenberg [:bagder] from comment #10)
> (I can see Firefox still resolve "mozilla.org" for me, which looks like a
> DNS leak bug but not as described here.)

I can reproduce by exactly following his steps.
And the call stack here was mentioned in comment 3.

Comment 12

[Daniel Stenberg [:bagder]]

Hm, curious that I didn't spot that resolve in my logs. But yeah, that's certainly code that actively does a name resolve and that will certainly work around the proxy config... To me that looks... wrong.

(btw, the mozilla.org resolve in my log is due to the connectivity checker and that's also wrong)

Comment 13

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

The leave-open keyword is there and there is no activity for 6 months.
:xeonchen, maybe it's time to close this bug?

Comment 14

[Gary Chen [:xeonchen]]

(In reply to Release mgmt bot [:sylvestre / :calixte] from comment #13)

The leave-open keyword is there and there is no activity for 6 months.
:xeonchen, maybe it's time to close this bug?

Thanks for reminding this :)

I don't remember why this patch wasn't reviewed, but apparently this bug is not resolved yet. :(

Comment 15

[Honza Bambas (:mayhemer)]

I may fix this as part of bug 1546924.

Comment 16

[Honza Bambas (:mayhemer)]

Dragana, is this the bug you were talking about on Thursday late evening with me on slack?

Comment 17

[Dragana Damjanovic [:dragana]]

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

Dragana, is this the bug you were talking about on Thursday late evening with me on slack?

No. I found that bug while looking at code because of some dns crash bug, but this is the same bug.

Comment 18

[Gary Chen [:xeonchen]]

Unassign myself since I'm not actively working on this.

Comment 19

[BMO Automation]

Moving bug to Core/Networking: Proxy.