MITM vector: ifupdown puts .domains TLD in resolv.conf

[Marques Johansson]

The bug described in https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1907878?comments=all is a security vulnerability because DNS names that would normally fail are now attempted as "foo.domains".

".domains" is a real TLD, with the registrar "Donuts, Inc." based in Bellvue, WA.
"google.com.domains" is registered, for example. So is "test.domains".

For users with ifupdown, any Internet request (especially that does not involve some cryptographic payload and destination signature verification) is potentially sending packets to an unintended audience. It's impossible to say, but likely, that malicious registrants are squatting sensitive and common names in the .domains TLD.

The ifupdown package is still used by some cloud providers that have not adopted netplan.
This vulnerability affects 22.04 and potentially other releases.

This issue has not been corrected in 0.8.36+nmu1ubuntu4.

With 0.8.36+nmu1ubuntu3 and after an update to 0.8.36+nmu1ubuntu4, the resolv.conf looks like the following (which is vulnerable to mitm attacks):

```
root@foo:~# cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search DOMAINS
```

[Seth Arnold (seth-arnold)]

Thanks for taking the time to report this bug and helping to make Ubuntu better. Since the package referred to in this bug is in universe or multiverse, it is community maintained. If you are able, I suggest coordinating with upstream and posting a debdiff for this issue. When a debdiff is available, members of the security team will review it and publish the package. See the following link for more information: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

[Seth Arnold (seth-arnold)]

Thanks Marques, do you know if this affects Debian as well? I wonder if they already saw this and fixed it, or if they don't yet know about it.

THanks

[Marques Johansson (marques)]

Debian 11's ifupdown 0.8.36 does not contain the /etc/network/if-up.d/resolved script that contains the DOMAINS=DOMAINS line.

The equivalent functionality in Debian comes from /etc/network/if-up.d/000resolvconf from the resolvconf package.

(I don't know if these are standard or if these are vendor customizations to the default package lists).

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Robert (rspier)]

Here's a quick-and-dirty temporary workaround:

It uses a post-up hook to remove DOMAINS=DOMAINS from the systemd-resolved state files if it ends up there. Put it in /etc/network/if-up.d/zzz-fix-domains

```
#!/bin/sh
statedir=/run/systemd/resolve/netif
grep -rl DOMAINS $statedir | xargs -r perl -pi -e 's/DOMAINS=DOMAINS//'
systemctl try-restart systemd-resolved || true
```

Running `resolvectl domains $INTERFACE ""` doesn't work because the network comes up before dbus, which is a prereq for systemd-resolved.

[Marques Johansson (marques)]

This is still a problem. Who would set the importance and assign someone to this?

[Marc Deslauriers (mdeslaur)]

It looks like debian/if-up.d/resolved contains a few occurrences of:

    DNS=DNS
    DOMAINS=DOMAINS

Perhaps it was supposed to be DNS=$DNS and DOMAINS=$DOMAINS, but someone will have to go through the script and figure out what the script is actually supposed to do and what the proper fix is.

The script is now in Debian too:

https://salsa.debian.org/debian/ifupdown/-/commit/0947ade06af1f4b7feb14cb7f1b1242afca2b3c6

[Marc Deslauriers (mdeslaur)]

There is possibly a fix in https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1907878/comments/15 , but I haven't tested it.

[Marc Deslauriers (mdeslaur)]

Similar issue here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031236

[Seth Arnold (seth-arnold)]

We were asked privately if this should receive a CVE. I'll copy my reply here:

In this case I don't believe a CVE is appropriate:

- DNS is typically plain-text unauthenticated

- DNS cache poisoning can be insanely easy if poor-quality DNS
  recursors are in use

- DNS cache poisoning is possible even if high-quality DNS recursors
  are in use

- DNSSEC can provide authentication of DNS results; end user sites can
  use a validating recursor to ensure that only authenticated results
  are delivered to applications

- Applications should be taking steps such as TLS or end-to-end data
  authenticity checks regardless of DNS authentication

Thanks

[Marques Johansson (marques)]

This is not a matter of cache poisoning. This is a 3rd-party owned domain suffix being applied to every name resolution on the system. Users using the default installed tools or deploying complex workloads will encounter this. When running Kubernetes on these nodes, for example, pods will inherit this behavior from the system through kube-dns.

Users' applications, package management, containers, and customer workloads request google.com, they get google.com.domains.

$ host google.com
google.com has address 142.251.40.174
google.com has IPv6 address 2607:f8b0:4006:823::200e
google.com mail is handled by 10 smtp.google.com.

$ host google.com.domains
google.com.domains has address 18.164.96.15
google.com.domains has address 18.164.96.65
google.com.domains has address 18.164.96.63
google.com.domains has address 18.164.96.112

This extends well beyond google. Every hostname "foo.com" that is registered on "com.domains" will be resolved to that com.domains domain. Likewise for any TLD.

$ host ubuntu.com.domains
ubuntu.com.domains has address 18.164.96.15
ubuntu.com.domains has address 18.164.96.112
ubuntu.com.domains has address 18.164.96.65
ubuntu.com.domains has address 18.164.96.63

$ host ubuntu.com
ubuntu.com has address 185.125.190.21
ubuntu.com has address 185.125.190.20
ubuntu.com has address 185.125.190.29
ubuntu.com has IPv6 address 2620:2d:4000:1::28
ubuntu.com has IPv6 address 2620:2d:4000:1::27
ubuntu.com has IPv6 address 2620:2d:4000:1::26
ubuntu.com mail is handled by 10 mx.ubuntu.com.

$ host archive.us.ubuntu.com.domains | tail -n1
archive.us.ubuntu.com.domains has address 18.164.96.15

$ host archive.ubuntu.com.domains | tail -n1
archive.ubuntu.com.domains has address 18.164.96.15

DNSSEC is not part of the configuration on Ubuntu's default package management tools (debian, python, perl). Nor are curl, wget, or most of the preinstalled system tools that traverse the internet protected by DNSSEC.

[Jun Aruga (junaruga)]

Hi I am seeing this issue `search DOMAINS` on Ubuntu jammy arm64 in the following environment.

```
$ cat /etc/os-release | grep ^VERSION
VERSION_ID="22.04"
VERSION="22.04.2 LTS (Jammy Jellyfish)"
VERSION_CODENAME=jammy

$ uname -m
aarch64

$ dpkg -S /etc/network/if-up.d/resolved
ifupdown: /etc/network/if-up.d/resolved

$ dpkg -s ifupdown | grep ^Version
Version: 0.8.36+nmu1ubuntu3
```

I saw the "search DOMAINS" in the /etc/resolv.conf.

```
$ cat /etc/resolv.conf | grep -v ^#

nameserver NNN.NNN.NNN.NNN (masked by myself)
options edns0 trust-ad
search DOMAINS
```

Then I tried the workaround script mentioned at https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1978351/comments/5 .

```
$ cat /etc/network/if-up.d/zzz-fix-domains
#!/bin/sh
statedir=/run/systemd/resolve/netif
grep -rl DOMAINS $statedir | xargs -r perl -pi -e 's/DOMAINS=DOMAINS//'
systemctl try-restart systemd-resolved || true
```

```
$ sudo chmod +x /etc/network/if-up.d/zzz-fix-domains
```

After running the `zzz-fix-domains`, the `search DOMAINS` was replaced with `search .`.

```
$ sudo /etc/network/if-up.d/zzz-fix-domains

$ grep -v ^# /etc/resolv.conf

nameserver NNN.NNN.NNN.NNN (masked by myself)
options edns0 trust-ad
search .
```

However, when rebooting OS, the `systemd-resolved` failed to start with booting.

```
...
[ OK ] Found device /sys/subsystem/net/devices/bond0.
[ OK ] Started ifup for bond0.
<email address hidden>
[ OK ] Started Network Configuration.
         Starting Wait for Network to be Configured...
systemd-networkd.service
         Starting Network Name Resolution...
[ OK ] Finished Wait for Network to be Configured.
systemd-networkd-wait-online.service
[ OK ] Started Network Name Resolution.
[ OK ] Reached target Host and Network Name Lookups.
systemd-resolved.service
         Stopping Network Name Resolution...
[ OK ] Stopped Network Name Resolution.
         Starting Network Name Resolution...
[ OK ] Started Network Name Resolution.
systemd-resolved.service
[ OK ] Finished Helper to synchronize boot up for ifupdown.
ifupdown-pre.service
         Starting Raise network interfaces...
         Stopping Network Name Resolution...
[ OK ] Stopped Network Name Resolution.
         Starting Network Name Resolution...
[ OK ] Started Network Name Resolution.
systemd-resolved.service
         Stopping Network Name Resolution...
[ OK ] Stopped Network Name Resolution.
         Starting Network Name Resolution...
[ OK ] Started Network Name Resolution.
systemd-resolved.service
         Stopping Network Name Resolution...
[ OK ] Stopped Network Name Resolution.
         Starting Network Name Resolution...
[ OK ] Started Network Name Resolution.
systemd-resolved.service
         Stopping Network Name Resolution...
[ OK ] Stopped Network Name Resolution.
[FAILED] Failed to start Network Name Resolution.
See 'systemctl status systemd-resolved.service' for details.
[ OK ] Finished Raise network interfaces.
...
```

The following log shows it failed with "Start request repeated too quickly".

```
Oct 18 12:37:48 ruby1 systemd[1]: systemd-resolved.service: Start request repeated too quickly.
Oct 18 12:37:48 ruby1 systemd[1]: syste...

[Jun Aruga (junaruga)]

> Anyone, could you tell me how to fix this issue, maybe adjusting the `zzz-fix-domains` script? Thanks.

I was able to fix this issue with another workaround even when rebooting OS. I didn't use the workaround script `/etc/network/if-up.d/zzz-fix-domains`. I added a new systemd service to run the `/usr/bin/resolvectl domain bond0 ""` in my case.

You can see the following link for details.
https://github.com/ruby/spec/issues/1095#issuecomment-1770537299