1663571 - (CVE-2020-26966) Info leak in the local area network when seach string(not domain) directly in the inbox(Windows 10)

Status: VERIFIED FIXED

(Core :: Networking: HTTP, defect, P1)

Description

[tiebuchen]

Attachment: pocfox.gif

When you search "WillBeLeakedString" directly in the inbox, the Firefox will send the mDNS "willbeleakedstring.local" packet and bordcast to the local area network.
I have tested in the LAN and I can monitor what my colleagues have searched in the Firefox inbox.
I can also monitor in the VMWare what I have searched in the Host Machine(see the poc.gif).

The result is that any node in the LAN can monitor what others(Windows10 OS) have searched in the inbox via the Firefox Browser.

Comment 1

[:Gijs (out for now; he/him)]

This is similar to bug 1642623 but the effects are probably worse. There's a hidden pref to turn this off ( introduced in bug 1642943 ).

The Firefox code that checks whether this is a valid hostname just calls the DNS service's AsyncResolve, and I'd expect either a DNS request or a DNS-over-HTTPS request, but not this.

I can reproduce seeing the mDNS packets on my mac with wireshark while making requests on my Windows box (on the same wifi network). I don't know why this would be the case; I'd expect a direct DNS query from the Windows box to the DNS server (which I don't see in wireshark). Valentin, do we send out the mDNS packets ourselves, or is Windows doing that, or...? Is there a way to not do that, and if so, what would the potential negative consequences be?

Comment 2

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

This seems to be caused by windows due to us calling getaddrinfo.
I've tried it in all browsers, as well as in a python shell using socket.gethostbyname and they all trigger a mdns query.

I am not very sure about how what the dns lookups for single word searches is supposed to do, but I assume it's to disambiguate between search and domain that exists on the local network?
In this case we can avoid the automatic mDNS lookup if we turn the hostname into FQDN by appending a . at the end. Any users that are actually trying to connect to something.local when typing something will have to add the .local part themselves.

Gijs, what do you think?

Comment 3

[:Gijs (out for now; he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

This seems to be caused by windows due to us calling getaddrinfo.
I've tried it in all browsers, as well as in a python shell using socket.gethostbyname and they all trigger a mdns query.

I am not very sure about how what the dns lookups for single word searches is supposed to do, but I assume it's to disambiguate between search and domain that exists on the local network?

Edit: forgot to answer this - yes, that's right. We default to searching, and then do the lookup more or less simultaneously. There's a pref to make the lookup happen first, and recently we added a pref to turn it off altogether (as noted earlier). This is all because Windows DNS is... really slow, for some people / reasons? So otherwise, searching single words takes a lot longer, as we have to resolve the DNS first and wait for that.

In this case we can avoid the automatic mDNS lookup if we turn the hostname into FQDN by appending a . at the end. Any users that are actually trying to connect to something.local when typing something will have to add the .local part themselves.

Gijs, what do you think?

Hm. I don't know how common the .local case is, maybe Marco has a better feel for it. However, from a quick web search, can we not use GetAddrInfoEx and specify we only want DNS, or would that have other drawbacks? ( https://docs.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfoexw )

Comment 4

[Marco Bonardo [:mak]]

We don't have telemetry about this, thus I can't tell you how much .local is used, or even just expected. My gut feeling is that one should type it explicitly, but it may be worth to check we're not breaking an expected flow; did you test what the other browsers are doing? Chromium is doing an identical dns request for these words, are they also querying for .local?

Comment 5

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

(In reply to :Gijs (he/him) from comment #3)

Hm. I don't know how common the .local case is, maybe Marco has a better feel for it. However, from a quick web search, can we not use GetAddrInfoEx and specify we only want DNS, or would that have other drawbacks? ( https://docs.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfoexw )

Good question. We already have bug 1500863 filed, but that is a non-trivial amount of work.
There's another issue that on windows we do a second DNS query just to get the TTL values, that are not available to the usual getaddrinfo call. I seem to remember the reason for doing this is that DnsQuery_A is really slow - so we do it later, with a lower priority.
Which is why I'm concerned about just switching to GetAddrInfoEx. I really think we should do it, but we might not be able to ship it if it has worse performance.

(In reply to Marco Bonardo [:mak] from comment #4)

We don't have telemetry about this, thus I can't tell you how much .local is used, or even just expected. My gut feeling is that one should type it explicitly, but it may be worth to check we're not breaking an expected flow; did you test what the other browsers are doing? Chromium is doing an identical dns request for these words, are they also querying for .local?

Yes, I also see a .local mdns query in Chrome & Edge too.

Comment 6

[Marco Bonardo [:mak]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

Yes, I also see a .local mdns query in Chrome & Edge too.

If so we may have to put querying .local behind a pref, to avoid breaking expectations (enterprise mostly, I guess?); thus make the default a FQDN request, but allow to revert to the old method through the pref.

Comment 7

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

(In reply to Marco Bonardo [:mak] from comment #6)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

Yes, I also see a .local mdns query in Chrome & Edge too.

If so we may have to put querying .local behind a pref, to avoid breaking expectations (enterprise mostly, I guess?); thus make the default a FQDN request, but allow to revert to the old method through the pref.

That sounds good to me.

Comment 8

[:Gijs (out for now; he/him)]

Attachment: Bug 1663571, r?mak

Comment 9

[:Gijs (out for now; he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

Yes, I also see a .local mdns query in Chrome & Edge too.

Reporter, have you or has someone else reported this to other browser vendors?

Comment 10

[tiebuchen]

I have reported this issue to other browser vendors at the same time.

Comment 11

[:Gijs (out for now; he/him)]

(In reply to tiebuchen from comment #10)

I have reported this issue to other browser vendors at the same time.

Can you link to such reports that are in public bugtrackers (even if the tickets are not publicly accessible - we can contact them out-of-band if we don't have access, but we need some way to reference the ticket) ? We'd like to not 0-day the other vendors with our fixes / release notes etc. if we can avoid it.

Comment 12

[:Gijs (out for now; he/him)]

Valentin, I have this patch now - but I realized that for DNS requests that happen inside the browser (for "normal" http requests; used for names on the exception list (ie known hostnames) stored in Firefox's prefs, and/or if the user or enterprise has set browser.fixup.dns_first_for_single_words to true), the same thing happens. Should we make the same change there somehow? Or would that be more risky?

Comment 13

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

(In reply to :Gijs (he/him) from comment #12)

Valentin, I have this patch now - but I realized that for DNS requests that happen inside the browser (for "normal" http requests; used for names on the exception list (ie known hostnames) stored in Firefox's prefs, and/or if the user or enterprise has set browser.fixup.dns_first_for_single_words to true), the same thing happens. Should we make the same change there somehow? Or would that be more risky?

I'm not exactly sure what the scenario you're talking about. Could you give some examples, and what these prefs are?

Comment 14

[:Gijs (out for now; he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #13)

(In reply to :Gijs (he/him) from comment #12)

Valentin, I have this patch now - but I realized that for DNS requests that happen inside the browser (for "normal" http requests; used for names on the exception list (ie known hostnames) stored in Firefox's prefs, and/or if the user or enterprise has set browser.fixup.dns_first_for_single_words to true), the same thing happens. Should we make the same change there somehow? Or would that be more risky?

I'm not exactly sure what the scenario you're talking about. Could you give some examples, and what these prefs are?

Sure. So the STR from comment 0 are effectively:

1. open firefox
2. type WillBeLeakedString in the URL bar
3. hit enter

then you hit the code in browser.js that's modified in the phabricator patch.

if you insert 1b.:

1b. open about:config, set browser.fixup.dns_first_for_single_words to true

then you won't hit that code - instead, we'll try to actually navigate to http://WillBeLeakedString/, and for that pageload we need to do a dns lookup, and that still uses mDNS for me.

The same situation will happen (without the dns_first_for_single_words pref set) if the single word / hostname was already listed as existing. By default just localhost is in that list, but when the DNS query in browser.js is successful in finding a host for the input string, it shows a notification bar, and by clicking the button on the notification bar (ie "Yes, I meant to go to http://<whatever>"), we add to the list. It's implemented using boolean prefs on the browser.fixup.domainwhitelist. pref prefix, ie browser.fixup.domainwhitelist.localhost is set to true by default, and in this case if you set the browser.fixup.domainwhitelist.willbeleakedstring pref to true, we'll also skip the search and go straight to navigating to http://<host>/.

Comment 15

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

Aha, I see. Thanks for the detailed explanation. This is a good question.

One option around this would be to turn the single label domain into a FQDN by adding a dot at the end in the DNS code. But that will break resolution of hostnames with a local domain suffix/workgroup, so it probably not what we want.

Another route would be to make the behaviour of dns_first_for_single_words be that we first resolve WillBeLeakedString. and if that fails we try WillBeLeakedString. But the added complexity of doing that for supporting non-default behaviour doesn't seem to be worth it.

In the end I think in the end it might be OK to land your patch and fix the bulk of this issue, and I'll try to implement bug 1500863 ASAP in order to cover dns_first_for_single_words and domainwhitelist cases. What do you think?

Comment 16

[:Gijs (out for now; he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #15)

Another route would be to make the behaviour of dns_first_for_single_words be that we first resolve WillBeLeakedString. and if that fails we try WillBeLeakedString. But the added complexity of doing that for supporting non-default behaviour doesn't seem to be worth it.

Right. We'd need to do this inside the http layer (at least, I'm assuming that's currently responsible for the lookups), too, which does make it more complicated.

I'd caveat the "non-default" behaviour though - AIUI, we will hit this case also for non-urlbar requests. That is, if a website has a link to http://foo/ and the user clicks it and/or we speculatively connect, we'll look up "foo" directly, without regard to the URL bar prefs. Sorry for not being explicit about this in my previous comment... though I suppose this is a less common case (ie far fewer people encounter such links than search from the address bar), and also we don't know how the internal Windows stuff is implemented. That is, if foo really exists (more plausible if you regularly use such links), I don't know if Windows internally does the "normal" nslookup first, and only resorts to the mDNS ones once the DNS server tells it there are no results.

In the end I think in the end it might be OK to land your patch and fix the bulk of this issue, and I'll try to implement bug 1500863 ASAP in order to cover dns_first_for_single_words and domainwhitelist cases. What do you think?

I agree, though I want to doublecheck that the above caveat doesn't change your opinion of whether this strategy is OK. :-)

Comment 17

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

(In reply to :Gijs (he/him) from comment #16)

I don't know if Windows internally does the "normal" nslookup first, and only resorts to the mDNS ones once the DNS server tells it there are no results.

I just checked, and yes. that's how it works.
If I put something in the windows version of /etc/hosts and go to http://something no mdns queries happen.
Same if I use my computer's hostname. But if I use something else that doesn't exist, I see mdns queries.

I'd caveat the "non-default" behaviour though - AIUI, we will hit this case also for non-urlbar requests. That is, if a website has a link to http://foo/ and the user clicks it and/or we speculatively connect, we'll look up "foo" directly,

This is indeed a bit concerning. I wonder if we should disallow speculative dns prefetch & preconnect to single label domains.

Comment 18

[:Gijs (out for now; he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #17)

This is indeed a bit concerning. I wonder if we should disallow speculative dns prefetch & preconnect to single label domains.

I filed bug 1664822 - I can write the patch if someone points me to the right place to check this in the speculative preconnect/prefetch code...

Do you think just disabling the prefetch will be sufficient to be able to ship this patch, too, and fix the remaining issue (for dns_first_for_single_words and navigations) in public bug 1500863?

Comment 19

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

(In reply to :Gijs (he/him) from comment #3)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

This seems to be caused by windows due to us calling getaddrinfo.

Hm. I don't know how common the .local case is, maybe Marco has a better feel for it. However, from a quick web search, can we not use GetAddrInfoEx and specify we only want DNS, or would that have other drawbacks? ( https://docs.microsoft.com/en-us/windows/win32/api/ws2tcpip/nf-ws2tcpip-getaddrinfoexw )

So, I have a WIP patch that uses GetAddrInfoExA on Windows. Problem is that even if I only specify the NS_DNS namespace, it still does mDNS resolution for single label queries.
I've tried to dig into it, to see if there's a way around it and I couldn't find anything. Other that disabling the mDNS service on the machine.

I'm thinking that the fix here really would be to append a . to every single label DNS query. Maybe only on windows?
I've checked that it doesn't break hosts defined in /etc/hosts or querying the hostname of the machine.

Comment 20

[:Gijs (out for now; he/him)]

phabbugz is broken but https://phabricator.services.mozilla.com/D90240 will likely supersede the patch I attached here. :-)

Comment 21

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

Attachment: Bug 1663571 - Turn single label DNS resolutions into FQDN r=Gijs

Comment 22

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

@Reporter, can you please link us to the reports for other browser vendors?
They are rather important in making sure we don't 0-day them. Thanks!

Comment 23

[tiebuchen]

OK, I will do that.
In fact I have submitted it to Chromium/Microsoft. However MSRC has closed the submition. Maybe I will submit it again to MSRC~
And now I can help to contact chromium team.

Comment 24

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

(In reply to tiebuchen from comment #23)

OK, I will do that.
In fact I have submitted it to Chromium/Microsoft. However MSRC has closed the submition. Maybe I will submit it again to MSRC~
And now I can help to contact chromium team.

What I mean is that you should post the links to the other reports here.
Thanks!

Comment 25

[tiebuchen]

https://bugs.chromium.org/p/chromium/issues/detail?id=1125909

Comment 26

[tiebuchen]

https://msrc.microsoft.com/report-detail/VULN-033342

Comment 27

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

Thank you!

Comment 28

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

Attachment: Bug 1663571 - Resolve single label DNS queries using DnsQuery_A r=dragana

Comment 29

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

Update: it seems resolving single label names with DnsQuery has the unfortunate side effect of not returning a record when resolving the computer name. I'll keep digging for a workaround. It seems this approach works well with respecting DNS suffix settings.

Comment 30

[:Gijs (out for now; he/him)]

Valentin, is this ready for landing?

Comment 31

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

Yes it is. I was considering to land it this week, but Chrome doesn't have a patch ready yet, so I was thinking to land it next week and uplift it to beta instead.

Comment 32

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

This had landed as https://hg.mozilla.org/integration/autoland/rev/3da0a14a9999a000af445ee3ed5fb4de7ef3bdeb

Backed out for making wpt tests unable to load initial page: https://hg.mozilla.org/integration/autoland/rev/f634bef79e0cee995c8ff9b4d94b650ce2877f0a

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunnable&revision=3da0a14a9999a000af445ee3ed5fb4de7ef3bdeb
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=319600436&repo=autoland

[task 2020-10-23T23:11:45.228Z] 23:11:45 INFO - Application command: C:\Users\task_1603493138\build\application\firefox\firefox.exe -marionette about:blank --wait-for-browser -profile c:\users\task_1603493138\appdata\local\temp\tmpzhosgt
[task 2020-10-23T23:11:45.228Z] 23:11:45 INFO - Starting runner
[task 2020-10-23T23:11:46.023Z] 23:11:46 INFO - PID 7328 | Can't find symbol 'eglSwapBuffersWithDamageEXT'.
[task 2020-10-23T23:11:46.023Z] 23:11:46 INFO - PID 7328 | Can't find symbol 'eglSetDamageRegionKHR'.
[task 2020-10-23T23:11:47.631Z] 23:11:47 INFO - PID 7328 | console.warn: SearchSettings: "get: No settings file exists, new profile?" (new Error("", "(unknown module)"))
[task 2020-10-23T23:11:48.185Z] 23:11:48 INFO - PID 7328 | 1603494708179 Marionette INFO Listening on port 49898
[task 2020-10-23T23:11:48.832Z] 23:11:48 CRITICAL - Loading initial page http://web-platform.test:8000/testharness_runner.html failed. Ensure that the there are no other programs bound to this port and that your firewall rules or network setup does not prevent access.
[task 2020-10-23T23:11:48.832Z] 23:11:48 CRITICAL - Traceback (most recent call last):
[task 2020-10-23T23:11:48.832Z] 23:11:48 CRITICAL - File "C:\Users\task_1603493138\build\tests\web-platform\tests\tools\wptrunner\wptrunner\executors\executormarionette.py", line 162, in load_runner
[task 2020-10-23T23:11:48.832Z] 23:11:48 CRITICAL - self.dismiss_alert(lambda: self.marionette.navigate(url))
[task 2020-10-23T23:11:48.832Z] 23:11:48 CRITICAL - File "C:\Users\task_1603493138\build\tests\web-platform\tests\tools\wptrunner\wptrunner\executors\executormarionette.py", line 210, in dismiss_alert
[task 2020-10-23T23:11:48.832Z] 23:11:48 CRITICAL - f()
[task 2020-10-23T23:11:48.832Z] 23:11:48 CRITICAL - File "C:\Users\task_1603493138\build\tests\web-platform\tests\tools\wptrunner\wptrunner\executors\executormarionette.py", line 162, in <lambda>
[task 2020-10-23T23:11:48.832Z] 23:11:48 CRITICAL - self.dismiss_alert(lambda: self.marionette.navigate(url))
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - File "C:\Users\task_1603493138\build\venv\lib\site-packages\marionette_driver\marionette.py", line 1501, in navigate
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - self._send_message("WebDriver:Navigate", {"url": url})
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - File "C:\Users\task_1603493138\build\venv\lib\site-packages\marionette_driver\decorators.py", line 27, in _
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - return func(*args, **kwargs)
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - File "C:\Users\task_1603493138\build\venv\lib\site-packages\marionette_driver\marionette.py", line 625, in _send_message
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - self._handle_error(err)
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - File "C:\Users\task_1603493138\build\venv\lib\site-packages\marionette_driver\marionette.py", line 647, in _handle_error
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - raise errors.lookup(error)(message, stacktrace=stacktrace)
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - UnknownException: Reached error page: about:neterror?e=dnsNotFound&u=http%3A//web-platform.test%3A8000/testharness_runner.html&c=UTF-8&d=We%20can%E2%80%99t%20connect%20to%20the%20server%20at%20web-platform.test.
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - stacktrace:
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - WebDriverError@chrome://marionette/content/error.js:181:5
[task 2020-10-23T23:11:48.833Z] 23:11:48 CRITICAL - UnknownError@chrome://marionette/content/error.js:488:5
[task 2020-10-23T23:11:48.834Z] 23:11:48 CRITICAL - checkReadyState@chrome://marionette/content/navigate.js:60:24
[task 2020-10-23T23:11:48.834Z] 23:11:48 CRITICAL - onNavigation@chrome://marionette/content/navigate.js:301:43

Comment 33

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

Landed as https://hg.mozilla.org/integration/autoland/rev/71c26eaf96b215581ca87b9b62954a1127d95f85

Backed out for causing mda failures in webrtc/tests/mochitests/test_peerConnection/*

https://hg.mozilla.org/integration/autoland/rev/b3557a86d1c37d82775ee290a94df2722256c80e

Push range: https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&fromchange=b5f6faabcb092fe073603a6d832cfbe009dc7ff8&searchStr=mda&tochange=3c57cdfde03a63d2716267a70f439759f90abc02&selectedTaskRun=etz1ayR9SauQOchESL0W0w.0
Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=319751191&repo=autoland

Comment 34

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

https://hg.mozilla.org/integration/autoland/rev/0344d5a76b7db85d4f6d5f5f34649b9111eb6094
https://hg.mozilla.org/mozilla-central/rev/0344d5a76b7d

Comment 35

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

Comment on attachment 9177340 [details]
Bug 1663571 - Resolve single label DNS queries using DnsQuery_A r=dragana

Beta/Release Uplift Approval Request

• User impact if declined: leak of single word searches to other local network computers via mDNS
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: Yes
• If yes, steps to reproduce: open wireshark. filter for dns || mdns
  do a single word search in the URL bar.
  Check that no mdns search is performed
• List of other uplifts needed: None
• Risk to taking this patch: Medium
• Why is the change risky/not risky? (and alternatives if risky): Using the new API may change behaviour in unexpected ways.
  We had to make an exception when the key matches the computer's name, and keep calling the old API - there may be other corner cases which are not well documented.
  On the bright side, this is guarded by a pref.
• String changes made/needed:

Comment 36

[tiebuchen]

Hi, Is this submission eligible for a bug bounty?

Comment 37

[Alin Ilea, Desktop Test Engineering]

Reproduced the initial issue in Beta 83.0b7 using Windows 10 and wireshark tool, following the steps from comment 35. There are both DNS and mDNS displayed using the "dns or mdns" filter in the Protocol column.
Verified - Fixed in latest Nightly 84.0a1 (build id: 20201102095541) on Windows 10. There is no mDNS displayed using the same "dns or mdns" filter after performing a single word search.

Comment 38

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9177340 [details]
Bug 1663571 - Resolve single label DNS queries using DnsQuery_A r=dragana

Approved for 83.0b8 and 78.5esr.

Comment 39

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/4b224d7d46ee

Comment 40

[Ryan VanderMeulen [:RyanVM]]

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

Comment 41

[Ryan VanderMeulen [:RyanVM]]

Backed out from ESR78 for build bustage:
https://hg.mozilla.org/releases/mozilla-esr78/rev/afa287afa0a3a2c9ac40478b16582675df52fa5e

Failure log:
https://treeherder.mozilla.org/logviewer?job_id=320616935&repo=mozilla-esr78&lineNumber=37798

Comment 42

[Daniel Veditz [:dveditz]]

(In reply to tiebuchen from comment #25)

https://bugs.chromium.org/p/chromium/issues/detail?id=1125909

I can't see that bug, but if I look at the chrome bug mentioned in bug 1642623 I see that they think the two issues are dupes.
https://bugs.chromium.org/p/chromium/issues/detail?id=479620#c144

Comment 43

[tiebuchen]

Hi,I don’t think they are dupes.The key part of this issue is the mDNS protocol in the LAN.If If no one points out the mDNS problem, it will not be fixed.In fact the issue of 1642623 has exited for years.

Comment 44

[tiebuchen]

@assignee

Comment 45

[tiebuchen]

The the same issue with 1642623 is the public one https://bugs.chromium.org/p/chromium/issues/detail?id=479620.However chromium deals my submission as a particularly bad sub-problem. vgosu@

Comment 46

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

I don't think this is a dupe of bug 1642623 and is in fact a new and separate issue.
But :dveditz is the one who can make the call if it qualifies for a bug bounty.

Comment 47

[tiebuchen]

Hi,
The chromium team set my report as a dupe and public it at first because of the misunderstanding of this vulnerability.
However they changed their minds after communication.

Comment 2 by [e-mail] on Wed, Sep 9, 2020, 2:01 AM GMT+8 Project Member

Status: Duplicate (was: Unconfirmed)
Labels: -Restrict-View-SecurityTeam
Mergedinto: 479620

Comment 3 by [e-mail] on Wed, Sep 9, 2020, 2:02 AM GMT+8 Project Member

Labels: allpublic

Comment 4 by [e-mail] on Wed, Sep 9, 2020, 3:13 AM GMT+8

Please see my poc again,it is not a mitm.It is that mdns protocal leaks the info.

Comment 6 by [e-mail] on Wed, Sep 9, 2020, 5:38 AM GMT+8 Project Member

Status: Assigned (was: Duplicate)
Owner: [e-mail]
Cc: [e-mail]
Labels: Security_Impact-Stable Security_Severity-Medium OS-Windows
Components: Privacy

I'll keep this open as a separate bug while we assess this a bit more (and so it's not immediately public).

security medium
privacy high
Pri:	1
Type:	Bug-Security

Comment 48

[tiebuchen]

PS : @[e-mail] is in the https://bugs.chromium.org/p/chromium/issues/detail?id=1125909 discussion group

Comment 49

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

Attachment: Bug 1663571 - [esr78] Resolve single label DNS queries using DnsQuery_A r=dragana

Comment 50

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

Comment on attachment 9185698 [details]
Bug 1663571 - [esr78] Resolve single label DNS queries using DnsQuery_A r=dragana

I rebased this on esr and fixed the build error.

Comment 51

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr78/rev/6b4cbc7eed70

Comment 52

[:Gijs (out for now; he/him)]

If chromium are still restricting their bug and have unduped, I think we should probably keep this hidden too, so gonna go ahead and re-add the sec group. My understanding is that this leak is to the local area LAN (so e.g. your coworkers could know what you searched for, but your ISP won't, from the mDNS query) whereas bug 1642623 is about your ISP finding out (but not your coworkers, as the "regular" DNS queries do not go to their machine). I'm sure Dan can/will revert if he feels strongly that this should remain unhidden.

Comment 53

[Daniel Veditz [:dveditz]]

Thanks for re-hiding, and for the earlier explanations from the Chrome bug.

Comment 54

[tiebuchen]

Hi, Is this submission eligible for a bug bounty or a CVE?

Comment 55

[Alin Ilea, Desktop Test Engineering]

Verified - Fixed in latest Beta 83.0b9 (build id: 20201105203649) on Windows 10. There is no mDNS displayed using the same "dns || mdns" filter after performing a single word search using Wireshark tool.

Comment 56

[Alin Ilea, Desktop Test Engineering]

Verified - Fixed in 78.5.0 ESR(build id: 20201104184202) on Windows 10.

Comment 57

[Tom Ritter [:tjr]]

Attachment: advisory.txt

Comment 58

[tiebuchen]

Hi, this submitting is not a dump one and
Is this submission eligible for a bug bounty?

Comment 59

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

It seems this fix breaks too many workflows.
I'm considering my new approach to detect whether the computer is on a public network, and only use the new API for those.

https://docs.microsoft.com/en-us/windows/win32/api/netlistmgr/ne-netlistmgr-nlm_network_category
https://docs.microsoft.com/en-us/windows/win32/api/netlistmgr/nf-netlistmgr-inetwork-getcategory

Comment 60

[Daniel Veditz [:dveditz]]

(In reply to tiebuchen from comment #58)

Hi, this submitting is not a [duplicate] one and Is this submission eligible for a bug bounty?

I took this off our bounty submission list when I thought it was a duplicate. Thanks for pointing that out and I've restored the nomination. However, bugs with a sec-low severity rating rarely qualify for a bounty. This will be evaluated by our bounty committee.

Comment 61

[:Gijs (out for now; he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) [vacation until Aug 1st] from comment #59)

It seems this fix breaks too many workflows.
I'm considering my new approach to detect whether the computer is on a public network, and only use the new API for those.

https://docs.microsoft.com/en-us/windows/win32/api/netlistmgr/ne-netlistmgr-nlm_network_category
https://docs.microsoft.com/en-us/windows/win32/api/netlistmgr/nf-netlistmgr-inetwork-getcategory

Hey Valentin, are you still working on this?

Comment 62

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

I have a WIP patch that works, but I'm unsure if it might also cause regressions.
Do you think we could land attachment 9174804 [details] instead? That should fix the majority of single label domain leaks.

Comment 63

[:Gijs (out for now; he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #62)

I have a WIP patch that works, but I'm unsure if it might also cause regressions.
Do you think we could land attachment 9174804 [details] instead? That should fix the majority of single label domain leaks.

Yeah, that works.

Comment 64

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

Attachment: WIP: Bug 1663571 - Only use DNS_QueryA for single label domains on public networks r=#necko

Comment 65

[:Gijs (out for now; he/him)]

How would we feel about landing the front-end patch in soft freeze? It already had r+...
I'm aware that there were previously regressions, but also AFAICT the trailing dot thing shouldn't break netbios resolution like before (cf. https://bugzilla.mozilla.org/show_bug.cgi?id=1677806#c6 ).

Comment 66

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

Either we land this now, or early in the next release cycle and uplift to beta. Either way it will be in Firefox 92. I am leaning toward landing now.
Btw, if I understand the code correctly, this would only fixup keyword to keyword. in the URL bar, but wouldn't turn http://word to http://word., right?

Comment 67

[:Gijs (out for now; he/him)]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #66)

Either we land this now, or early in the next release cycle and uplift to beta. Either way it will be in Firefox 92. I am leaning toward landing now.
Btw, if I understand the code correctly, this would only fixup keyword to keyword. in the URL bar, but wouldn't turn http://word to http://word., right?

Yes, I believe so.

Comment 68

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

r=mak
https://hg.mozilla.org/integration/autoland/rev/585ee494976fee18c13f999bb91f3dcaa535c531
https://hg.mozilla.org/mozilla-central/rev/585ee494976f

Comment 69

[Ryan VanderMeulen [:RyanVM]]

Tracking for this bug is pretty messy at this point. I assume we'll want to get this newer fix onto ESR91 next cycle too?

Comment 70

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

Yes, we should try to land attachment 9174804 [details] on ESR91 too.

Comment 71

[Alin Ilea, Desktop Test Engineering]

Hi,
@Valentin, should I verify the Nightly 92 fix by following the same steps from comment 35, are those steps still valid in order to verify this?
Thanks!

Comment 72

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

Yes, the steps are still valid.

Comment 73

[Alin Ilea, Desktop Test Engineering]

Thanks for the answer.
Verified - Fixed in latest Nightly 93.0a1 (2021-08-09) and Nightly 92.0a1 (2021-08-08) on Windows 10. There is no mDNS displayed in Wireshark using the "dns || mdns" filter after performing a single word search (only DNS is displayed).

Comment 74

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for ESR91 approval when you get a chance.

Comment 75

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

Comment on attachment 9174804 [details]
Bug 1663571, r?mak

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration:
• User impact if declined: Single word inputs to the URL bar will be broadcast to the local network via mDNS in the attempt to determine if that word is the name of a computer on the network.
  This is a builtin behaviour of getaddrinfo on Windows. This fix works around that by appending a . to the name, turning it into a FQDN, which prevents the mDNS request from happening.
• Fix Landed on Version: 92
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Chrome has shipped a similar fix to this problem, so the risk is low here.
  As opposed to the previous attempted fix, fixing the issue in the URL bar ensures we only change the behaviour when one searches for a word, not when someone attempts to load http://oneword.
  This change is also guarded by a pref which we can disable through normandy if we see any problems.
• String or UUID changes made by this patch:

Comment 76

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9174804 [details]
Bug 1663571, r?mak

Approved for 91.1esr.

Comment 77

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/cf092366a25d

Comment 78

[Alin Ilea, Desktop Test Engineering]

Verified - Fixed in 91.1.0esr (build id: 20210812202727) using Windows 10.