[Touch-packages] [Bug 1978351] Re: MITM vector: ifupdown puts .domains TLD in resolv.conf

2023-10-19 Thread Jun Aruga
> 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


** Bug watch added: github.com/ruby/spec/issues #1095
   https://github.com/ruby/spec/issues/1095

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1978351

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

Status in ifupdown package in Ubuntu:
  Confirmed

Bug description:
  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
  ```

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1978351/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp


[Touch-packages] [Bug 1978351] Re: MITM vector: ifupdown puts .domains TLD in resolv.conf

2023-10-18 Thread Jun Aruga
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.
ifup@bond0.service
[  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]: systemd-resolved.service: Failed with result 
'start-limit-hit'.
```


```
$ sudo systemctl status systemd-resolved.service
× systemd-resolved.service - Network Name Resolution
 Loaded: loaded (/lib/systemd/system/systemd-resolved.service; enabled; 
vendor preset: enabled)
 Active: failed (Result: start-limit-hit) since Wed 2023-10-18 12:37:48 
UTC; 20min ago
   Docs: man:systemd-resolved.service(8)
 man:org.freedesktop.resolve1(5)
 
https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
 
https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
Process: 2021 ExecStart=/lib/systemd/systemd-resolved (code=exited, 
status=0/SUCCESS)
   Main PID: 2021 (code=exited, status=0/SUCCESS)
 Status: "Shutting down..."
CPU: 69ms

Oct 18 12:37:47 ruby1 systemd-resolved[2021]: . IN DS 20326 8 2 
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Oct 18 12:37:47 ruby1 systemd-resolved[2021]: Negative trust anchors: home.arpa 
10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 
19.172.in-addr.arpa 20.172.in-a>
Oct 18 12:37:47 ruby1 systemd-resolved[2021]: Using system hostname 'ruby1'.
Oct 18 12:37:47 ruby1 systemd[1]: Started Network Name Resolution.
Oct 18 12:37:48 ruby1 systemd[1]: Stopping Network Name Resolution...
Oct 18 12:37:48 ruby1 systemd[1]: systemd-resolved.service: Deactivated 
successfully.
Oct 18 12:37:48 ruby1 systemd[1]: Stopped Network Name Resolution.
Oct 18 12:37:48 ruby1 systemd[1]: systemd-resolved.service: Start request 
repeated too quickly.
Oct 18 12:37:48 ruby1 systemd[1]: systemd-resolved.service: Failed with result 
'start-limit-hit'.
Oct 18 12:37:48 ruby1 systemd[1]: Failed to start Network Name Resolution.