6 ms·

Remote execution bug in BSD ping

48 points by AndrewDucker 4y ago

bell-cot 4y ago
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. IV. Workaround No workaround is available. [...]
- shashasha2 4y ago
  Workaround : rm /usr/bin/ping
  - deleted 4y ago
    [deleted]
  - bell-cot 4y ago
    If an old server can't be patched, and is gonna stay that way for longer than "oh, I remember that vulnerability being announced a week ago", then chmod 4500 /sbin/ping mv /sbin/ping /sbin/ping_CVE-2022-23093 and put a few-lines shell script in /sbin/ping, which spits out a reminder of the vulnerability, and exits non-zero.
kloch 4y ago
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.
- jdsnape 4y ago
  The former I believe
- tinus_hn 4y ago
  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.
jakeogh 4y ago
Affects: All supported versions of FreeBSD. What about older versions?
- bell-cot 4y ago
  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"):
g0xA52A2A 4y ago
Title should be "FreeBSD" rather than the all encompassing "BSD".
trasz2 4y ago
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.
- bell-cot 4y ago
  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...
  - trasz2 4y ago
    If you have a way to make them ping your host at just the right moment, and then keep that ping process running.
pajko 4y ago
Could MacOS be affected? A not insignificant part of the userland comes from FreeBSD.
- pajko 4y ago
  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' [0] https://github.com/freebsd/freebsd-src/commit/46d7b45a267b3d78c5054b210ff7b6c55bfca42b https://github.com/freebsd/freebsd-src/commit/46d7b45a267b3d... [1] https://github.com/freebsd/freebsd-src/commit/d9cacf605e2ac0f704e1ce76357cbfbe6cb63d52 https://github.com/freebsd/freebsd-src/commit/d9cacf605e2ac0... [2] https://opensource.apple.com/source/network_cmds/network_cmds-543.50.4/ping.tproj/ping.c.auto.html https://opensource.apple.com/source/network_cmds/network_cmd...
Semtexzv 4y ago
You should RIIR

48 points by AndrewDucker 4y ago

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. IV. Workaround No workaround is available. [...]

shashasha2 4y ago
Workaround : rm /usr/bin/ping
- deleted 4y ago
  [deleted]
- bell-cot 4y ago
  If an old server can't be patched, and is gonna stay that way for longer than "oh, I remember that vulnerability being announced a week ago", then chmod 4500 /sbin/ping mv /sbin/ping /sbin/ping_CVE-2022-23093 and put a few-lines shell script in /sbin/ping, which spits out a reminder of the vulnerability, and exits non-zero.

kloch 4y ago

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.

jdsnape 4y ago
The former I believe
tinus_hn 4y ago
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.

jakeogh 4y ago

Affects: All supported versions of FreeBSD. What about older versions?

bell-cot 4y ago
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"):

g0xA52A2A 4y ago

Title should be "FreeBSD" rather than the all encompassing "BSD".

trasz2 4y ago

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.

bell-cot 4y ago
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...
- trasz2 4y ago
  If you have a way to make them ping your host at just the right moment, and then keep that ping process running.

pajko 4y ago

Could MacOS be affected? A not insignificant part of the userland comes from FreeBSD.

pajko 4y ago
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' [0] https://github.com/freebsd/freebsd-src/commit/46d7b45a267b3d78c5054b210ff7b6c55bfca42b https://github.com/freebsd/freebsd-src/commit/46d7b45a267b3d... [1] https://github.com/freebsd/freebsd-src/commit/d9cacf605e2ac0f704e1ce76357cbfbe6cb63d52 https://github.com/freebsd/freebsd-src/commit/d9cacf605e2ac0... [2] https://opensource.apple.com/source/network_cmds/network_cmds-543.50.4/ping.tproj/ping.c.auto.html https://opensource.apple.com/source/network_cmds/network_cmd...

Semtexzv 4y ago

You should RIIR