From nobody Tue Dec 23 21:01:30 2025 X-Original-To: freebsd-security@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4dbS9c1qpKz6KrYx for ; Tue, 23 Dec 2025 21:01:40 +0000 (UTC) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [IPv6:2607:f3e0:0:1::12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smarthost1.sentex.ca", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dbS9b6S0Cz47WK for ; Tue, 23 Dec 2025 21:01:39 +0000 (UTC) (envelope-from mike@sentex.net) Authentication-Results: mx1.freebsd.org; none Received: from pyroxene2a.sentex.ca (pyroxene19.sentex.ca [199.212.134.19]) by smarthost1.sentex.ca (8.18.1/8.18.1) with ESMTPS id 5BNL1Vo1078718 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=FAIL); Tue, 23 Dec 2025 16:01:31 -0500 (EST) (envelope-from mike@sentex.net) Received: from [IPV6:2607:f3e0:0:4:25a9:f019:da19:aa51] ([IPv6:2607:f3e0:0:4:25a9:f019:da19:aa51]) by pyroxene2a.sentex.ca (8.18.1/8.15.2) with ESMTPS id 5BNL1UaM096554 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 23 Dec 2025 16:01:30 -0500 (EST) (envelope-from mike@sentex.net) Message-ID: <1c9897c2-a6cc-4fb7-b6df-896c55272d4d@sentex.net> Date: Tue, 23 Dec 2025 16:01:30 -0500 List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: FreeBSD-SA-25:12.rtsold.asc clarification needed (mostly clarified) To: Karl Denninger , freebsd-security@freebsd.org References: <20251222210308.4352ee6f@Hydrogen> <479965af-2f24-4ee5-b938-adc1e5eea2a4@sentex.net> <20251222211100.3f245825@Hydrogen> <20251222215128.212a1040@Hydrogen> <9db9807a-a05e-4bcf-85b5-8e921db91f5b@denninger.net> Content-Language: en-US From: mike tancsa Autocrypt: addr=mike@sentex.net; keydata= xsBNBFywzOMBCACoNFpwi5MeyEREiCeHtbm6pZJI/HnO+wXdCAWtZkS49weOoVyUj5BEXRZP xflV2ib2hflX4nXqhenaNiia4iaZ9ft3I1ebd7GEbGnsWCvAnob5MvDZyStDAuRxPJK1ya/s +6rOvr+eQiXYNVvfBhrCfrtR/esSkitBGxhUkBjOti8QwzD71JVF5YaOjBAs7jZUKyLGj0kW yDg4jUndudWU7G2yc9GwpHJ9aRSUN8e/mWdIogK0v+QBHfv/dsI6zVB7YuxCC9Fx8WPwfhDH VZC4kdYCQWKXrm7yb4TiVdBh5kgvlO9q3js1yYdfR1x8mjK2bH2RSv4bV3zkNmsDCIxjABEB AAHNHW1pa2UgdGFuY3NhIDxtaWtlQHNlbnRleC5uZXQ+wsCOBBMBCAA4FiEEmuvCXT0aY6hs 4SbWeVOEFl5WrMgFAl+pQfkCGwMFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQeVOEFl5W rMiN6ggAk3H5vk8QnbvGbb4sinxZt/wDetgk0AOR9NRmtTnPaW+sIJEfGBOz47Xih+f7uWJS j+uvc9Ewn2Z7n8z3ZHJlLAByLVLtcNXGoRIGJ27tevfOaNqgJHBPbFOcXCBBFTx4MYMM4iAZ cDT5vsBTSaM36JZFtHZBKkuFEItbA/N8ZQSHKdTYMIA7A3OCLGbJBqloQ8SlW4MkTzKX4u7R yefAYQ0h20x9IqC5Ju8IsYRFacVZconT16KS81IBceO42vXTN0VexbVF2rZIx3v/NT75r6Vw 0FlXVB1lXOHKydRA2NeleS4NEG2vWqy/9Boj0itMfNDlOhkrA/0DcCurMpnpbM7ATQRcsMzk AQgA1Dpo/xWS66MaOJLwA28sKNMwkEk1Yjs+okOXDOu1F+0qvgE8sVmrOOPvvWr4axtKRSG1 t2QUiZ/ZkW/x/+t0nrM39EANV1VncuQZ1ceIiwTJFqGZQ8kb0+BNkwuNVFHRgXm1qzAJweEt RdsCMohB+H7BL5LGCVG5JaU0lqFU9pFP40HxEbyzxjsZgSE8LwkI6wcu0BLv6K6cLm0EiHPO l5G8kgRi38PS7/6s3R8QDsEtbGsYy6O82k3zSLIjuDBwA9GRaeigGppTxzAHVjf5o9KKu4O7 gC2KKVHPegbXS+GK7DU0fjzX57H5bZ6komE5eY4p3oWT/CwVPSGfPs8jOwARAQABwsB2BBgB CAAgFiEEmuvCXT0aY6hs4SbWeVOEFl5WrMgFAl+pQfkCGwwACgkQeVOEFl5WrMiVqwf9GwU8 c6cylknZX8QwlsVudTC8xr/L17JA84wf03k3d4wxP7bqy5AYy7jboZMbgWXngAE/HPQU95NM aukysSnknzoIpC96XZJ0okLBXVS6Y0ylZQ+HrbIhMpuQPoDweoF5F9wKrsHRoDaUK1VR706X rwm4HUzh7Jk+auuMYfuCh0FVlFBEuiJWMLhg/5WCmcRfiuB6F59ZcUQrwLEZeNhF2XJV4KwB Tlg7HCWO/sy1foE5noaMyACjAtAQE9p5kGYaj+DuRhPdWUTsHNuqrhikzIZd2rrcMid+ktb0 NvtvswzMO059z1YGMtGSqQ4srCArju+XHIdTFdiIYbd7+jeehg== In-Reply-To: <9db9807a-a05e-4bcf-85b5-8e921db91f5b@denninger.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.86 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:11647, ipnet:2607:f3e0::/32, country:CA] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dbS9b6S0Cz47WK On 12/22/2025 5:25 PM, Karl Denninger wrote: >> >> When I asked if patching the userland code was enough, you said no. >> >> From what I understand having ACCEPT_RTADV on an interface means the >> kernel is processing rtadv packets.  The advisory mentions that, but >> it seems thats not sufficient to trigger the bug, as rtsold is the >> one that processes the unchecked DNS info.  i.e. you need both >> ACCEPT_RTADV enabled and rtsold enabled, no ? If just having >> ACCEPT_RTADV enabled would lead to an exploit, that implies a kernel >> bug no ? >> >> I just want to confirm if *not* running rtsold is enough to avoid >> this bug or just having the mere presence of IPv6 can lead to >> exploit. If the latter, how is that actually working. >> >>     ---Mike >> > Unless I am missing something serious you are correct. > > Without rtsold if you have an interface that goes down and comes back > up you likely will not get routes (including default) until the > gateway performs its next timed transmission (typically 10 minutes.) > > With it enabled but no options specified it comes up on my machines as > "-a -i" which is "seek the interfaces to solicit upon and do so > immediately on start." > > The problem is that the resolvconf(8) script is run by default (unless > you specify something else with the -R switch) if rtsold is running > and a DNS configuration option (RDNSS or DNSSL) advertisement is > received.  If rtsold is not running then it should not result in a > problem per-se however you get the possibility of not having routes > when the box comes up until the gateway performs its next timed > transmission. > Thanks for the hints.  I spent a bit of time figuring out more details on how this might and might not work TL;DR, on RELENG_14 at least, I can get an IPV6 addr and default route without /sbin/rtsol which is what *is* being fired at bootup time by /etc/rc. It does not fire after that it seems ever. So any unpatched box that has inet6 accept_rtadv enabled in /etc/rc.conf on an interface, or ipv6_activate_all_interfaces="YES" is indeed vulnerable at bootup time since /sbin/rtsol -i is called then. After that, without a reboot, /sbin/rtsol does not seem to be called.  If rtsold is not running, info being passed from the router to the client being what "passive SLAAC" does (address and route) does not seem to be processed. My test router thats handing out ip6 addrs is set to mininterval=120 em0::addr="2607:f3e0:xx:xx::":prefixlen#64:" :rdnss="2001:4860:4860::8888,2001:4860:4860::8844":\ :mininterval#120:\ :dnssl="sentex.net": On my test box I added an anon dtrace probe to fire when /sbin/rtsol is called. dtrace -A -n 'syscall::execve:entry /strstr(copyinstr(arg0), "rtsol") != NULL/ { printf("\n--- CAUGHT RTSOL ---\nCaller Name: %s\nCaller Args: %s\nParent PID: %d\n", execname, curpsinfo->pr_psargs, ppid); }' Sure enough over serial I see even with the physical interface down /sbin/rtsol getting called. # dtrace -a CPU     ID                    FUNCTION:NAME   3  82297                     execve:entry --- CAUGHT RTSOL --- Caller Name: sh Caller Args: /bin/sh -o verify /etc/rc autoboot Parent PID: 221 so the bootup process does indeed call the userland /sbin/rtsol to configure the ipv6 address. I then renamed /sbin/rtsol to be just a shell script that exits out and as expected, no ipv6 address when I have ifconfig_igc0="DHCP" ifconfig_igc0_ipv6="inet6 accept_rtadv" in /etc/rc.conf Box booted up with igc0 disconnected and I am in via serial # ifconfig igc0 igc0: flags=8843 metric 0 mtu 1500 options=4e427bb         ether 60:be:b4:29:19:b2         inet6 fe80::62be:b4ff:fe29:19b2%igc0 prefixlen 64 scopeid 0x1         media: Ethernet autoselect         status: no carrier         nd6 options=23 I startup dtrace to watch, and it seems just the one call at bootup time (in /etc/network.subr)  dtrace -a CPU     ID                    FUNCTION:NAME   2  82297                     execve:entry --- CAUGHT RTSOL --- Caller Name: sh Caller Args: /bin/sh -o verify /etc/rc autoboot Parent PID: 223 I physically connect the NIC, but no ipv6 address of course.  A few min later, later I get an advertisement and response solicitation and I get an IP and default route. Even though DNS and domain info are pushed in the packet (confirmed via pcap), they dont get processed since rtsol does not get called in this format and rtsold is not running. This sort of seems to make sense based on what I have found about "passive SLAAC" on FreeBSD. ifconfig igc0 | grep RT         nd6 options=23 If I do a service rtsold enable it looks different, but expected. My anon dtrace prob sees the same rtsol call from the bootup script and then rtsold is also started.  dtrace -a CPU     ID                    FUNCTION:NAME   0  82297                     execve:entry --- CAUGHT RTSOL --- Caller Name: sh Caller Args: /bin/sh -o verify /etc/rc autoboot Parent PID: 221   0  82297                     execve:entry --- CAUGHT RTSOL --- Caller Name: limits Caller Args: limits -C daemon /usr/sbin/rtsold -a -i Parent PID: 592 I reboot with the interface up, I still see /sbin/rtsol being called and rtsold properly processes the full response to update my /etc/resolv.conf However, if I startup the box with the physical ethernet down, I still have to wait for the router to do its periodic advertisement. devd on the physical interface coming up does not call /sbin/rtsol in my case so I have to wait for the periodic advertisement from the upstream router.