[Touch-packages] [Bug 1825378] Re: systemd-networkd doesn't set wireguard peer endpoint
disco-proposed fixed it for me as well: - Clean disco installation. - Create .netdev file. - reboot --> Endpoint is not set. - Update systemd from disco-proposed. - reboot --> Endpoint is set. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1825378 Title: systemd-networkd doesn't set wireguard peer endpoint Status in systemd package in Ubuntu: Fix Committed Status in systemd source package in Cosmic: Invalid Status in systemd source package in Disco: Fix Committed Status in systemd source package in Eoan: Fix Committed Bug description: [impact] systemd does not set endpoints for wireguard interfaces correctly. This makes wireguard unusable. [test case] install a disco or eoan system and set up a wireguard interface: $ sudo add-apt-repository ppa:wireguard/wireguard $ sudo apt install wireguard ...(this does a lot of stuff)... create a file as below; There is no need to setup remote server to reproduce this issue, but PublicKey/PrivateKey should be valid one (used instructions from https://www.linode.com/docs/networking/vpn /set-up-wireguard-vpn-on-ubuntu/#configure-wireguard-server): $ cat /etc/systemd/network/wg0.netdev [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=uMuCbguKYdKanRYMbDSriIdgxGxJR57Us1zEy8wRc1M= ListenPort=51820 [WireGuardPeer] PublicKey=ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 $ sudo systemctl restart systemd-networkd $ sudo wg show wg0 interface: wg0 public key: BnvFgvPiVb5xURfzZ5liV1P77qeGeJDIX3C1iNquA2k= private key: (hidden) listening port: 51820 peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= allowed ips: 10.0.0.0/8 the last command should print remote endpoint address, e.g.: peer: ZRyl+kvb6o2/6Da5YLum6GnSrzDj3J002+2kmK5CnS4= endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 [regression potential] any changes to systemd contain the potential for serious regressions. However, this is cherry picked directly from upstream, with the releases requiring patching (disco and eoan) being at exactly the same version and very close to upstream already. Additionally, while this does add 2 new functions (from upstream commit https://github.com/systemd/systemd/pull/11580/commits/abd48ec87f2ac5dd571a99dcb4db88c4affdffc8), they are only used - and code is only changed in - wireguard.c, so any regressions should be limited to wireguard interfaces (unless systemd crashes completely). [other info] this bug is not present in cosmic and earlier, and is already fixed in upstream systemd, so this is needed only for disco and eoan. original description: --- systemd/disco 240 shipped with Ubuntu 19.04 beta does not set endpoints for [WireguradPeer] properly. This regression was introduced in v241 and merged into v240. systemd 241 doesn't set wireguard peer endpoint https://github.com/systemd/systemd/issues/11579 Revert of the regression was landed on v240 stable branch https://github.com/systemd/systemd-stable/pull/39 1)2) confirmed with, systemd/disco 240-6ubuntu5 amd64 3) put a netdev file /etc/systemd/network/wg0.netdev --- [NetDev] Name=wg0 Kind=wireguard [WireGuard] PrivateKey=** ListenPort=51820 [WireGuardPeer] PublicKey=* AllowedIPs=10.0.0.0/8 Endpoint=192.168.1.1:51820 and run --- # systemctl restart systemd-networkd # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * allowed ips: 10.0.0.0/8 4) the last command should print remote endpoint address. --- # wg show wg0 interface: wg0 public key: * private key: (hidden) listening port: 51820 peer: * endpoint: 192.168.1.1:51820 allowed ips: 10.0.0.0/8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1825378/+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 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes
Has there been any progress so far? systemd-resolved would be nice in theory, but not if it breaks half of the websites like it did before I stopped using it. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: In Progress Status in systemd source package in Bionic: In Progress Status in systemd source package in Cosmic: In Progress Status in systemd source package in Disco: In Progress Bug description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes
I think the downgrade behaviour of systemd-resolved is the same as in that upstream bug although it is triggered differently. Except that it only breaks that single NXDOMAIN query in my case while it sounds like a permanent failure in the upstream bug. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: New Bug description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes
** Attachment added: "Filtered packet capture" https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+attachment/5198078/+files/systemd-resolved-bug.pcapng -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: New Bug description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1796501] [NEW] systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes
Public bug reported: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New ** Attachment added: "Commands including output" https://bugs.launchpad.net/bugs/1796501/+attachment/5198077/+files/systemd-resolved-bug.commands -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1796501 Title: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes Status in systemd package in Ubuntu: New Bug description: I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the following steps: 1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size. 2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit. 3. Ask upstream for SOA of test.asdf. with EDNS0. 4. Ask upstream for SOA of test.asdf. without EDNS0. 5. Repeat 1-4 for DS of test.asdf. 6. Repeat 1-5 for asdf. 7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size. 8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size. The upstream returns an unfragmented NXDOMAIN response for steps 1-6, an unfragmented NOERROR response for step 7 and a fragmented NOERROR response for step 8 which is the correct behaviour. DNSSEC records are included in the response if the DO-bit in the request was set. systemd-resolved should take the response from step 1 and start with validation instead of starting useless retries with reduced feture set. Step 3 and 4 are completely useless and probably lead to the SERVFAIL because I have configured it with DNSSEC=yes to prevent downgrade attacks. This regression seems to be caused by the patch resolved-Mitigate- DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic should only be executed if it is configured as DNSSEC=allow-downgrade or DNSSEC=no. See also https://github.com/systemd/systemd/pull/8608#issuecomment-396927885. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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
