Remote execution bug in BSD ping | Hacker News Reader

Remote execution bug in BSD ping

freebsd.org

48 pointsAndrewDucker15 comments

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.

[...]

Workaround : rm /usr/bin/ping

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.

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

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.

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...

If you have a way to make them ping your host at just the right moment, and then keep that ping process running.

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.

The former I believe

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.

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

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/46d7b45a267b3d...

[1] https://github.com/freebsd/freebsd-src/commit/d9cacf605e2ac0...

[2] https://opensource.apple.com/source/network_cmds/network_cmd...

  Affects: All supported versions of FreeBSD.

What about older versions?

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"):

You should RIIR

Reply on news.ycombinator.com