Remote execution bug in BSD ping(freebsd.org)

48 pointsby AndrewDuckervor 4 Jahren15 comments

https://www.freebsd.org/security/advisories/FreeBSD-SA-22:15.ping.asc

16 comments

bell-cotvor 4 Jahren

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.

[...]

shashasha2vor 4 Jahren

Workaround : rm /usr/bin/ping

bell-cotvor 4 Jahren

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.

[deleted]vor 4 Jahren

g0xA52A2Avor 4 Jahren

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

trasz2vor 4 Jahren

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-cotvor 4 Jahren

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

trasz2vor 4 Jahren

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

klochvor 4 Jahren

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.

tinus_hnvor 4 Jahren

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.

jdsnapevor 4 Jahren

The former I believe

pajkovor 4 Jahren

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

pajkovor 4 Jahren

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

jakeoghvor 4 Jahren

  Affects: All supported versions of FreeBSD.

What about older versions?

bell-cotvor 4 Jahren

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

Semtexzvvor 4 Jahren

You should RIIR