Re:Remote execution bug in BSD ping
by bell-cot on Wednesday November 30, 2022 @05:41AM
(#33799055)
Below is the guts of the advisory. Some crude workarounds - changing permission on /sbin/ping, blocking ping packets with a firewall, etc. - would be fairly trivial to implement.
[...]
Affects: All supported versions of FreeBSD.
[...]
II. Problem Description
ping reads raw IP packets from the network to process responses in the
pr_pack() function. As part of processing a response ping has to
reconstruct the IP header, the ICMP header and if present a "quoted
packet," which represents the packet that generated an ICMP error. The
quoted packet again has an IP header and an ICMP header.
The pr_pack() copies received IP and ICMP headers into stack buffers
for further processing. In so doing, it fails to take into account the
possible presence of IP option headers following the IP header in
either the response or the quoted packet. When IP options are present,
pr_pack() overflows the destination buffer by up to 40 bytes.
III. Impact
The memory safety bugs described above can be triggered by a remote
host, causing the ping program to crash. It may be possible for a
malicious host to trigger remote code execution in ping.
The ping process runs in a capability mode sandbox on all affected
versions of FreeBSD and is thus very constrainted in how it can interact
with the rest of the system at the point where the bug can occur.
Re:Remote execution bug in BSD ping
by kloch on Wednesday November 30, 2022 @12:08PM
(#33803757)
Does this require a user to be executing ping while a remote attacker sends a flood of exploit packets? Or is the OS always vulnerable? The article was not clear on this point.
Re:Remote execution bug in BSD ping
by tinus_hn on Thursday December 01, 2022 @03:09AM
(#33813622)
The user uses the command to ping the attacker and the attacker returns a manipulated packet. Sounds far-fetched but there might be services that allow you to check if pings from the internet can reach you.
Re:Remote execution bug in BSD ping
by bell-cot on Wednesday November 30, 2022 @04:43PM
(#33808201)
Ignoring the "you should never run unsupported versions, due to security..." choir - I agree that it'd be awesome if they'd just tell us a bit about older versions.
From a couple quick 'diff' comparison between the oldest supported ping.c source code (12.3-RELEASE) and the source code from an older version (10.3-RELEASE) that I had convenient...ping.c has seen far more changes than I expected. (I'm not a c / networking guru, to very quickly tell if the older stuff shares the vulnerability. Nor do I have the time to dig into this. So my non-answer amounts to "Better Assume the Worst"):
Re:Remote execution bug in BSD ping
by trasz2 on Thursday December 01, 2022 @06:40AM
(#33815016)
Note that in FreeBSD, ping is sandboxed using capsicum, so the impact of this is rather low - you can get ping to crash, and send arbitrary packets, and write arbitrary stuff to the terminal, and I think that's it.
Re:Remote execution bug in BSD ping
by bell-cot on Thursday December 01, 2022 @10:45AM
(#33817777)
If I'm trying to penetrate somebody's network, then being able to send arbitrary packets - from an "inside" server, running a vulnerable ping binary' - sounds pretty darn useful. Maybe I can compromise a device or ten further out, which the vulnerable server occasionally pings. Maybe I've got a botnet, which returns malicious ping replies to IP #'s on my current "would be useful to compromise" list. Maybe...
Re:Remote execution bug in BSD ping
by pajko on Thursday December 01, 2022 @07:50AM
(#33815579)
Seems like so. The fix [0] mainly replaces memcpys added by a former commit [1], which seems to be the main difference between the FreeBSD and Apple variant of ping [2], but probably that's not the source of the bug. What smells in there is 'hlen = ip->ip_hl << 2'
[...]
Affects: All supported versions of FreeBSD.
[...]
II. Problem Description
ping reads raw IP packets from the network to process responses in the pr_pack() function. As part of processing a response ping has to reconstruct the IP header, the ICMP header and if present a "quoted packet," which represents the packet that generated an ICMP error. The quoted packet again has an IP header and an ICMP header.
The pr_pack() copies received IP and ICMP headers into stack buffers for further processing. In so doing, it fails to take into account the possible presence of IP option headers following the IP header in either the response or the quoted packet. When IP options are present, pr_pack() overflows the destination buffer by up to 40 bytes.
III. Impact
The memory safety bugs described above can be triggered by a remote host, causing the ping program to crash. It may be possible for a malicious host to trigger remote code execution in ping.
The ping process runs in a capability mode sandbox on all affected versions of FreeBSD and is thus very constrainted in how it can interact with the rest of the system at the point where the bug can occur.
IV. Workaround
No workaround is available.
[...]
From a couple quick 'diff' comparison between the oldest supported ping.c source code (12.3-RELEASE) and the source code from an older version (10.3-RELEASE) that I had convenient...ping.c has seen far more changes than I expected. (I'm not a c / networking guru, to very quickly tell if the older stuff shares the vulnerability. Nor do I have the time to dig into this. So my non-answer amounts to "Better Assume the Worst"):
[0] https://github.com/freebsd/freebsd-src/commit/46d7b45a267b3d...
[1] https://github.com/freebsd/freebsd-src/commit/d9cacf605e2ac0...
[2] https://opensource.apple.com/source/network_cmds/network_cmd...