Home Assistant OS leaks private host names to cloudflare DNS service (CVE-2020-36517)

[mtdcr]

Describe the issue you are experiencing

Home Assistant OS always gets configured to load-balance between my DNS resolver and Cloudflare's. I already looked under every stone, but there's no way to disable this behavior using configuration options.

So if I use DNS names configured by my router instead of hard-coding IP addresses, HA will switch over to Cloudflare from time to time and leak my internal hostnames to their service. Of course resolution fails in this case, too. Note that this is not caused by the hard-coded fallback option, but by the hard-coded load-balancing option.

One way to avoid this could be blocking 1.1.1.1 and 1.0.0.1 in my firewall, but then HA's DNS resolver goes berserk flooding my firewall logs with multiple connection attempts per second. Also, this will break further whenever developers decide to switch their user base from Cloudflare to a new data collection service.

What operating system image do you use?

ova (for Virtual Machines)

What version of Home Assistant Operating System is installed?

7.1

Did you upgrade the Operating System.

Yes

Steps to reproduce the issue

1. Insert local hostname in HA config
2. Notice recurring failures in name resolution
3. Notice packets going to 1.0.0.1 and 1.1.1.1

Anything in the Supervisor logs that might be useful for us?

-

Anything in the Host logs that might be useful for us?

Typical output of `ha dns log` when the service gets blocked.
~~~
[INFO] 127.0.0.1:44130 - 10230 "NS IN . udp 17 false 512" NOERROR - 0 30.001023101s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:51517 - 36166 "NS IN . udp 17 false 512" NOERROR - 0 30.000661016s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:34985 - 13557 "NS IN . udp 17 false 512" NOERROR - 0 30.001216215s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:39902 - 40031 "NS IN . udp 17 false 512" NOERROR - 0 30.000821668s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:43380 - 37784 "NS IN . udp 17 false 512" NOERROR - 0 30.000649803s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:60231 - 1526 "NS IN . udp 17 false 512" NOERROR - 0 30.000941436s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:42409 - 17159 "NS IN . udp 17 false 512" NOERROR - 0 30.001298402s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:37011 - 7485 "NS IN . udp 17 false 512" NOERROR - 0 30.00056859s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:46069 - 34633 "NS IN . udp 17 false 512" NOERROR - 0 30.001109111s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:52199 - 55341 "NS IN . udp 17 false 512" NOERROR - 0 30.000769912s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:44575 - 61374 "NS IN . udp 17 false 512" NOERROR - 0 30.000521003s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
[INFO] 127.0.0.1:59716 - 56622 "NS IN . udp 17 false 512" NOERROR - 0 30.001314379s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
[INFO] 127.0.0.1:43202 - 11517 "NS IN . udp 17 false 512" NOERROR - 0 30.000960835s
[ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
~~~

System Health information

No response

Additional information

No response

[tic226n]

I have (like many others[0]) the same problem. I noticed my firewall logs being flooded with DNS lookups to cloudflare servers. This is just bad design and quite frankly, it is ridiculous. The usual workaround of creating a dedicated block rule for the hardcoded cloudflare servers prevents entries being added to the logs and works well enough. Shame on the hass.io developers for ignoring this issue.

Edit: To make this 'future' proof i created an inverted block rule that blocks every DNS query from the HA host (53/853) that is not directed at my local DNS server.

[0] https://community.home-assistant.io/t/local-dns/178108/85

[philipflesher]

+1 -- same issue.

[Strohhutpat]

+1 -- same issue.

[mschilt]

same issue here.. would be great if HA would only use the configured, internal DNS Server and not ping out to Cloudflare. As far as I understood this is part of some kind of failback mechanism. I think that mechanism is probably not working correctly since my local DNS Service never has availability issues.

[liudab]

Same issue here, and there are numerous attempts to dial 1.0.0.1:853 and 1.1.1.1:853. I tried to had edited /usr/share/hassio/dns.json and /usr/share/hassio/dns/coredns.json, not help with issue, and this issue slowed down my local network. Pls fix this issue, and let users choose.

Feb 24 10:29:33 raspberrypi c25c8d59d674[766]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
Feb 24 10:29:35 raspberrypi c25c8d59d674[766]: [INFO] 127.0.0.1:43745 - 14836 "NS IN . udp 17 false 512" NOERROR - 0 30.001163805s
Feb 24 10:29:35 raspberrypi c25c8d59d674[766]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
Feb 24 10:29:36 raspberrypi c25c8d59d674[766]: [INFO] 127.0.0.1:43857 - 18263 "NS IN . udp 17 false 512" NOERROR - 0 30.000670555s
Feb 24 10:29:36 raspberrypi c25c8d59d674[766]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
Feb 24 10:29:38 raspberrypi c25c8d59d674[766]: [INFO] 127.0.0.1:46192 - 23166 "NS IN . udp 17 false 512" NOERROR - 0 30.000614263s
Feb 24 10:29:38 raspberrypi c25c8d59d674[766]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout
Feb 24 10:29:39 raspberrypi c25c8d59d674[766]: [INFO] 127.0.0.1:41931 - 46048 "NS IN . udp 17 false 512" NOERROR - 0 30.000839356s
Feb 24 10:29:39 raspberrypi c25c8d59d674[766]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.1.1.1:853: i/o timeout
Feb 24 10:29:41 raspberrypi c25c8d59d674[766]: [INFO] 127.0.0.1:54422 - 21526 "NS IN . udp 17 false 512" NOERROR - 0 30.00059314s
Feb 24 10:29:41 raspberrypi c25c8d59d674[766]: [ERROR] plugin/errors: 2 . NS: dial tcp 1.0.0.1:853: i/o timeout

[hermanops]

+1 -- same issue.

[jaytea33]

There are tons of threads on this problem and the devs continue to ignore it. I don't think functioning DNS is an unreasonable request

https://community.home-assistant.io/t/ha-os-dns-setting-configuration-not-respected/356572/12

UPDATE: So the gist of it is this - don't count on this issue getting fixed any time soon or possibly ever. Dev's position is that prior to implementing this unholy bastardization of DNS, they had tons of support issues due to user DNS misconfigurations. So they issued a forced DNS fallback to ensure they don't waste their time troubleshooting it, and it's been great for them in their cozy ivory tower while users who actually understand how DNS is supposed to work are left to bash our heads trying to get around this downright abysmal implementation. I expect this behavior from Chinese IoT devices - not an open source project.

For many of us, the whole point of using HA is to localize everything as MUCH as possible! Clearly, there are some philosophical differences at work here, and it just ends up with threads either being locked or the issue ignored/going stale, then being bumped by justifiably frustrated users to no avail. This seems like much more of a corporate direction (maybe because Nabu Casa is the focus?), and if it keeps up, I can only hope someone with more development skills than I can fork HA to a build that prioritizes local IoT, security, non-retarded DNS, and embraces the open-source philosophy of user control and choice, similar to the Emby/Jellyfin treatment when Emby became corporate and unusable.

Anyway, rant over, time for the solution that so far seems to work for me:

Use this add-on to remove the forced fallback (among other things for advanced users):

https://github.com/bentasker/HomeAssistantAddons/tree/master/core-dns-override

While I'm not sure if both are necessary, I also used the AdGuard solution at the bottom of this page:

https://community.home-assistant.io/t/dns-configuration-help/182258/10

Just make sure to follow the instructions correctly for setting up AdGuard - it feels weird setting the HA Host to use a static Public DNS IP but the Upstream DNS configuration makes sense.

One thing to note though, after making any change in DNS, whether changing the HA Host's DNS IP or changing something in AdGuard, I've noticed that I have to restart the "Core DNS Override" addon, and then it reflects the new DNS config immediately (I'm assuming because it restarts the Core DNS service?).

Using the AdGuard setup instructions, you can easily add your local domain by configuring the Upstream DNS - just follow the examples below the fields, they're very clear. Then restart "Core DNS Override" addon and try nslookup against your local domain to verify it resolves.

The last piece I had to figure out was redirecting my duckdns.org name to my local HA IP. This was previously handled by my router (which then points to NGINX Proxy Manager in HA) and for devices outside HA, it resolves locally just fine, so entering in with fake, redirected SSL still worked. But from HA's perspective, it's still looking at my Public IP when using nslookup against my duckdns.org name. It turns out the fix is simple even though it took me a while to find:

In AdGuard, go to "Filters > DNS Rewrites > click "Add DNS rewrite" - then it's just like a classic hostfile edit at that point. Commit it, restart "Core DNS Override" again.

Hopefully this helps someone else struggling with these DNS issues (or devs decide to listen and we get a proper fix, but not holding my breath).

[mtdcr]

There's a CVE ID for this issue now: CVE-2020-36517.

[hermanops]

my firewall reports over 20.000 dns-leaks per minute to Cloudflare on port 853

[mdegat01]

Just an FYI for everyone, I believe #85 actually fixes most of the issues identified here since MDNS and LLMNR names are no longer forwarded to external resolvers. That covers everything except local hostnames that aren't MDNS and LLMNR. There is a follow-up PR to add an option to disable the fallback DNS here: https://github.com/home-assistant/supervisor/pull/3586 . That should finish this out and allow you to stop those from being forwarded as well.

[candybars2021]

this issue is absolutely disgusting and makes me think twice before I continue to use this insecure system. The fact that home assistant circumvents my firewall DNS settings, which includes block rules that in my mind are vital, and forces me to allow access to external port 853, is unacceptable and completely contradicts the whole privacy concept behind homeassistant. If this isn't fixed properly, and DNS rewrites do not work (I haven't tried the workaround suggested yet, although the idea of having to circumvent the whole system and not enable updates that would trample my legitimate right to resolve my own DNS and not have my network flooded by cloudflare-DNS.com requests every few seconds, making my net work unusable, is unacceptable and immoral in my opinion. I truly don't understand the reason the developers have chosen to circumvent the whole philosophy behind homeassistant, and I don't by the fact that this is "easier"for less technically experienced users, as if this were the case, no device would work on any simple home router because no DNS query that is in Forced on the user, would work. It raises the question, of what exactly home assistant is trying to resolve through the "back door" (more like the front gate if you ask me), and what kind of traffic is allowed, since the result is ignoring firewall rules and security limitations by brute force. I can circumvent any DNS traffic from any device, prevent hardcoded google DNS settings on android devices (another cheap trick) easily, but not with this. of the 50 smart home devices that I have on my network, homeassistant is the only one that insists on not playing "by the rules ", figuratively and literally. I don't trust the system that prevents smart speakers from conecting directly to the Internet, and charge his money for them to connect through its own cloud, yet forces free access to all of its many services, some of whom I have no idea or trust that are essential, to protect my privacy. Looking at network flows, even when this unfathomable external access is enabled, there's endless traffic to the Internet where nothing is happening supposedly and everything is disabled in terms of control over smart home devices. Even if I were imagining that home assistant is using this trick for banned access, the mere fact that this exists, reduces my trust in this system to absolute zero, and makes me think the whole thing is a sham. For people who don't use the next generation firewall, or meticulously go through the logs, the impression that this is a secure segregation between their smart home devices on the Internet, with safe control is all internal, this amounts to fraud. I urge home assistant to fix this issue, and do it fast, or else as an attorney I will act on state DA,FCC and Better Business Bureau levels, as well as civil class action lawsuit and this can be viewed as prior notice. The fact that this is "freeware", that takes scores of hours to configure before you realize how much time you have wasted, does not remove any of the responsibility, and responsibility for damages incurred as a result of installing the system and configuring it, only to realize everything mentioned above, creates civil and criminal liability that should be kept in mind when insisting on maintaining the status quo. This response is just the beginning and will be followed up if necessary, i.e. not entirely fixed and very soon.

[livebelive]

@candybars2021 太棒了！！！！！我支持你！如果需要联名诉讼，请算我一个！几年前接触得HA，到现在感觉面目全非了，我最近还遇到关于时区设置的问题，无论怎么设置，HA底层的时间都跟我的时区不一致。。。即使我改了我底层esxi的时间，依然无效！一个简简单单的时间，在配置上却十分的繁琐，翻遍了网络上的帖子，也没找到解决方案。。。最后还要借助第三方的插件来修正。。。如果有第二个选择，我将毫不犹豫换掉HA！

[foequeue]

I just happened to start using HA and noticed the flood of failed DNS from the docker container. It doesn't appear that my local dns has any failures and yet it STILL is trying to hit cloudflare? I white listed the ip as an experiment and it STILL tried to hit cloudflare. I can only agree to the "easier for me, not for thee" is a disgusting mantra and to not have a setting IN THE GUI to turn this behavior off is intentional. Question to the devs - would you accept a PR with that wired up? If no, then why not?