Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
On 18/06/2024 16:39, Martin-Éric Racine wrote: ti 18. kesäk. 2024 klo 15.52 Nicolas Cavallari (nicolas.cavall...@green-communications.fr) kirjoitti: On 18/06/2024 13:14, Martin-Éric Racine wrote: su 16. kesäk. 2024 klo 9.05 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari (nicolas.cavall...@green-communications.fr) kirjoitti: I didn't check if there were any adverse effect or if leases are still renewed. I can't check on the production system before Monday. Please let me know. Any news on this? My dedicated server receives leases of 86400s, it takes a while to check if leases are renewed correctly. Noted. After two days and multiples renews, I can confirm that it works. For Stable, this is what I would upload, once you've confirmed that the 3 cherry-picks work: dhcpcd5 (9.4.1-24~deb12u4) bookworm; urgency=medium * Add --no-stop-on-upgrade --no-restart-after-upgrade (Closes: #1057959). * Cherry-pick upstream backported fixes for RC bug (Closes: #1050805). * Update dhcpcd.preinst version check to match current one. On the plus side, no attempt will be made to restart it, to prevent connection loss. On the minus side, it means that the administrator must restart manually or reboot. Well, needrestart exists, so i don't have an issue with this.
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
On 18/06/2024 13:14, Martin-Éric Racine wrote: su 16. kesäk. 2024 klo 9.05 Martin-Éric Racine (martin-eric.rac...@iki.fi) kirjoitti: la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari (nicolas.cavall...@green-communications.fr) kirjoitti: I didn't check if there were any adverse effect or if leases are still renewed. I can't check on the production system before Monday. Please let me know. Any news on this? My dedicated server receives leases of 86400s, it takes a while to check if leases are renewed correctly. I installed it today. For some reason, dhcpcd was stopped when upgrading the 'dhcpcd' package but was not restarted afterward. Looking at the dhcpcd maintainer scripts, I see the deb-systemd-invoke stop in preinst but i don't see any start in postinst or anywhere else.
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
On 16/06/2024 08:05, Martin-Éric Racine wrote: la 15. kesäk. 2024 klo 16.55 Nicolas Cavallari (nicolas.cavall...@green-communications.fr) kirjoitti: On 15/06/2024 11:33, Martin-Éric Racine wrote: Upstream got around releasing a backport of this for branch 9 as commits 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 and 6e127eac6903524d401b31893167e4529b8ab111 respectively. You are hereby invited to test and report whether this fixes it for Stable. I did some quick tests on a VM: First, with 9.4.1-24~deb12u3 as present in debian stable: Then I apt sourced dhcpcd, applied the two patches, rebuilt debian packages and tested them. The situation is now worse: I then tested this patch from issue #283: https://github.com/NetworkConfiguration/dhcpcd/commit/727c78f503d456875e2a3cee7609288b537d9d25.patch And this time, it appears to fix the problem: So you had to apply 3 patches to fix 9.4.1 in Stable? The 2 aforementioned ones and the one from upstream issue 283? Yes, I applied 3 patches.
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
On 15/06/2024 11:33, Martin-Éric Racine wrote:
On Tue, 29 Aug 2023 13:17:51 +0200 Nicolas Cavallari
wrote:
Package: dhcpcd-base
Version: 9.4.1-22
Severity: critical
Tags: security
Justification: breaks unrelated software
X-Debbugs-Cc: Debian Security Team
When the dhcpcd DHCPv4 client receives a zero-length UDP packet on port
68, the "network proxy" dhcpcd process exits with status 0. dhcpcd then
stops all network activity: It does not renew leases and eventually expires
the current lease (unless it has infinite duration) and removes the IP
address, leaving the system without networking.
This bug can be triggered remotely over the internet from any UDP port
and is critical on an internet-facing system that needs DHCP to get
an IP address, such as a gateway, a dedicated server or a VM.
This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2
(stable proposed update) but not 1:10.0.2-4 (testing/unstable) as
upstream fixed it in 10.0.2:
Upstream Bug report: https://github.com/NetworkConfiguration/dhcpcd/issues/179
Upstream Fix:
https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae
This patch does not apply cleanly to 9.4.1 because the privsep
structure changed in 10.0.2. It's likely that only the src/privsep.c
hunks about len == 0 and eloop_exit() needs to be backported, the other
changes are just here to avoid compiler warnings about unused
parameters.
Upstream got around releasing a backport of this for branch 9 as
commits 53e2f6de4ba87d0534c89cae674e6c1a48724ef0 and
6e127eac6903524d401b31893167e4529b8ab111 respectively.
You are hereby invited to test and report whether this fixes it for Stable.
I did some quick tests on a VM:
First, with 9.4.1-24~deb12u3 as present in debian stable:
# dhcpcd
dhcpcd-9.4.1 starting
dev: loaded udev
DUID 00:04:56:44:13:1b:34:73:40:28:95:70:ba:03:3b:94:d1:45
enp1s0: IAID 00:a5:5a:70
enp1s0: rebinding lease of 192.168.122.51
enp1s0: leased 192.168.122.51 for 3600 seconds
enp1s0: adding route to 192.168.122.0/24
enp1s0: adding default route via 192.168.122.1
forked to background, child pid 1211
# ps ax | grep dhcpcd
1211 ?S 0:00 dhcpcd: [manager] [ip4] [ip6]
1212 ?S 0:00 dhcpcd: [privileged proxy]
1213 ?S 0:00 dhcpcd: [network proxy]
1214 ?S 0:00 dhcpcd: [control proxy]
1217 ?S 0:00 dhcpcd: [BPF ARP] enp1s0 192.168.122.51
1235 pts/0S+ 0:00 grep dhcpcd
# python3 -c 'from socket import *; socket(AF_INET,
SOCK_DGRAM).sendto(b"", ("127.0.0.1", 68))'
# ps ax | grep dhcpcd
1211 ?S 0:00 dhcpcd: [manager] [ip4] [ip6]
1212 ?S 0:00 dhcpcd: [privileged proxy]
1214 ?S 0:00 dhcpcd: [control proxy]
1217 ?S 0:00 dhcpcd: [BPF ARP] enp1s0 192.168.122.51
1239 pts/0S+ 0:00 grep dhcpcd
The network proxy (1213) is gone.
Then I apt sourced dhcpcd, applied the two patches, rebuilt debian
packages and tested them. The situation is now worse:
# ps ax | grep dhcpcd
1492 ?S 0:00 dhcpcd: [manager] [ip4] [ip6]
1493 ?S 0:00 dhcpcd: [privileged proxy]
1494 ?S 0:00 dhcpcd: [network proxy]
1495 ?S 0:00 dhcpcd: [control proxy]
1498 ?S 0:00 dhcpcd: [BPF ARP] enp1s0 192.168.122.51
1516 pts/0S+ 0:00 grep dhcpcd
# python3 -c 'from socket import *; socket(AF_INET,
SOCK_DGRAM).sendto(b"", ("127.0.0.1", 68))'
[ 1851.428513] dhcpcd[1492]: segfault at 4 ip 004eecd8 sp bf980af0 error
4 in dhcpcd[4cd000+4] likely on CPU 2 (core 0, socket 2)
[ 1851.428523] Code: c4 20 83 c4 0c 5b 5e 5f 5d c3 8d b4 26 00 00 00 00
90 55 89 d5 57 89 c7 56 53 e8 13 0c fe ff 81 c3 63 d0 03 00 83 ec 1c 8b
00 <8b> 52 04 8b 80 78 01 00 00 8b 30 85 f6 0f 84 9c 00 00 00 8d 47 0c
# ps ax | grep dhcpcd
1493 ?S 0:00 dhcpcd: [privileged proxy]
1494 ?S 0:00 dhcpcd: [network proxy]
1498 ?S 0:00 dhcpcd: [BPF ARP] enp1s0 192.168.122.51
1521 pts/0S+ 0:00 grep dhcpcd
The network proxy survived, but the manager and control proxy didn't.
And SIGTERM is not enough to kill the remaining processes.
I then tested this patch from issue #283:
https://github.com/NetworkConfiguration/dhcpcd/commit/727c78f503d456875e2a3cee7609288b537d9d25.patch
And this time, it appears to fix the problem:
# ps ax | grep dhcp
3248 ?S 0:00 dhcpcd: [manager] [ip4] [ip6]
3249 ?S 0:00 dhcpcd: [privileged proxy]
3250 ?S 0:00 dhcpcd: [network proxy]
3251 ?S 0:00 dhcpcd: [control proxy]
3254 ?S 0:00 dhcpcd: [BPF ARP] enp1s0 192.168.122.51
3272 pts/1S+ 0:00 grep dhcp
# python3 -c 'from socket import *; socket(AF_INET,
SOCK_DGRAM).sendto(b"", ("127.0.0.1", 68))'
# ps ax | grep dhcp
3248 ?S 0:00 dhcpcd: [manager] [ip4] [ip6]
3249 ?S 0:00 dhcpcd: [privilege
Bug#1050805: dhcpcd-base: DoS: zero-length packet cause eventual lease expiration
Package: dhcpcd-base Version: 9.4.1-22 Severity: critical Tags: security Justification: breaks unrelated software X-Debbugs-Cc: Debian Security Team When the dhcpcd DHCPv4 client receives a zero-length UDP packet on port 68, the "network proxy" dhcpcd process exits with status 0. dhcpcd then stops all network activity: It does not renew leases and eventually expires the current lease (unless it has infinite duration) and removes the IP address, leaving the system without networking. This bug can be triggered remotely over the internet from any UDP port and is critical on an internet-facing system that needs DHCP to get an IP address, such as a gateway, a dedicated server or a VM. This affects version 9.4.1-22 (stable) and 1:9.4.1-24~deb12u2 (stable proposed update) but not 1:10.0.2-4 (testing/unstable) as upstream fixed it in 10.0.2: Upstream Bug report: https://github.com/NetworkConfiguration/dhcpcd/issues/179 Upstream Fix: https://github.com/NetworkConfiguration/dhcpcd/commit/8b29c0ddf026c1c5647c3b8c6cfe21699c4056ae This patch does not apply cleanly to 9.4.1 because the privsep structure changed in 10.0.2. It's likely that only the src/privsep.c hunks about len == 0 and eloop_exit() needs to be backported, the other changes are just here to avoid compiler warnings about unused parameters. -- System Information: Debian Release: 12.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1.0-11-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages dhcpcd-base depends on: ii adduser 3.134 ii libc6 2.36-9+deb12u1 ii libudev1 252.12-1~deb12u1 Versions of packages dhcpcd-base recommends: pn wpasupplicant Versions of packages dhcpcd-base suggests: ii openresolv [resolvconf] 3.12.0-3 -- Configuration Files: /etc/dhcpcd.conf changed [not included] -- no debconf information
Bug#1003907: fails to successfully associate
On 21/03/2022 09:38, Andrej Shadura wrote: Hi, On Sun, 20 Mar 2022, at 00:23, Masashi Honma wrote: In my opinion, this issue could be closed. These are reasons. 1) It is not wpa_supplicant issue but AP issue. 2) Users affected by this issue have some workarounds. It’s true, but I’m not quite happy about not being able to fix this. Ľubomír (cc'ed), how did you deal with this issue in Fedora? I assume you must also have received reports from Fritzbox users. Details of the 1) The investigation has revealed that the AP is in violation of "2.3 WPA3-Personal transition mode" of the "WPA3 Specification v3.0", which is causing the issue. Specifically, the target AP is setting MFPR to 1 even though it implicitly requires IEEE 802.11w. By "implicitly" we mean that the Assocation Request fails with WLAN_STATUS_INVALID_IE when using a Wi-Fi NIC with IEEE 802.11w disabled. (I assume Masashi meant "the target AP is setting MFPC to 0"). Details of the 2) We know that users who meet the following conditions are affected by this issue. - Using FRITZ!Box 7580/7590 with WPA2+WPA3 mode - Using wpa_supplicant with wpa_key_mgmt=SAE WPA-PSK - Local Wi-Fi NIC does not support IEEE802.11w Users affected by this issue can work around the issue in one of the following ways. - Use wpa_supplicant with WPA2 only mode (specify wpa_key_mgmt=WPA-PSK) - Use FRITZ!Box 7580/7590 with WPA2 only mode - Use IEEE 802.11w supporting Wi-Fi NIC The WPA3 spec also indicate that when a non-AP STA uses WPA3, it must use 802.11w. A strict interpretation of this spec would indicate that SAE should not be used by hardware without 802.11w support. Complying to this spec could be a workaround: "if WPA-PSK and SAE are advertised, MFPR is not set and local hardware does not support MFP, do not use SAE". This could however degrade security to APs that comply to the 802.11 specifications without complying to Wi-Fi specifications (i.e. which do not advertise themselves as "Wi-Fi").
Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init
On 03/02/2019 13:32, Axel Beckert wrote: > Hi Nicolas! > > Nicolas Cavallari wrote: >> I do not have cgroupsfs-mount installed, but i have elogind. > > Interesting. I have elogind installed, too, and I also have that > mountpoint at /sys/fs/cgroup/elogind, but nevertheless, uninstalling > cgroupfs-mount sufficed for me. IIRC I didn't do a reboot since then, > though. I forgot another important piece of information (because i lost the original response while trying to reproduce the bug): udev is started in rcS.d, way before elogind, which is in rc2.d. The result is that, at boot, udev clearly logs that it does not detect cgroups, so it will not make its sigkilling spree. But after elogind is started, the cgroups are created. udev really needs to be restarted after that point to have it detect the cgroups and trigger the bug. That, and udev must detect that its parent pid is 1, which can happen quickly when launched by start-stop-daemon --background.
Bug#918764: udev: "udevadm control --reload-rules" kills all processes except init
Package: udev Version: 240-5 Followup-For: Bug #918764 I do not have cgroupsfs-mount installed, but i have elogind. It apparently mounts /sys/fs/cgroup/unified, so this is enough for udev to think it is under systemd. A typical /proc/self/cgroup is : 1:name=elogind:/ 0::/ So it is my understanding from the source code that manager->cgroup should contain '/'. A debugging session breaking on on_post() very unhelpfully indicates that 'manager', 'manager->cgroup', 'userdata' and other helpful variables have been optimized out... (I only use elogind to satisfy the overly broad dependencies of libpolkit-qt5-1-1, but that is another bug, #794537). -- Package-specific info: -- System Information: Debian Release: buster/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'oldoldstable'), (500, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-2-amd64 (SMP w/2 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to fr_FR.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages udev depends on: ii adduser 3.118 ii libacl1 2.2.52-3+b1 ii libblkid12.33.1-0.1 ii libc62.28-5 ii libkmod2 25-2 ii libselinux1 2.8-1+b1 ii libudev1 240-5 ii lsb-base 10.2018112800 ii util-linux 2.33.1-0.1 udev recommends no packages. udev suggests no packages. Versions of packages udev is related to: pn systemd -- Configuration Files: /etc/init.d/udev changed [not included] /etc/udev/udev.conf changed [not included] -- debconf information excluded
