Be careful with that ping, FreeBSD

Out of the blue, an interesting Common Vulnerabilities and Exposures (CVE), formally called CVE-2022-23093 has emerged, which exploits one of the fundamental tools of the Internet stack: Ping, the command that implements the Internet Control Message Protocol (ICMP) as it’s universally known.

ICMP is baked into the Internet Protocol (IP) as a supplement; it shares many of the packet structure properties but is designed to be part of the IP layer, not to provide service for higher data processes. That said, people have, of course, found novel ways to use the ‘payload’ fragment of ICMP. For example, it’s possible to get IP over ICMP. That generality, which normally is a feature of how people do things in the IP world, also carries with it the seeds of the attack at hand — ICMP is capable of doing more than people think.

What’s going on here? Well, ICMP is designed as its full name says, to be a ‘control message’ protocol. The utility that implements ICMP is called ‘ping’ because it’s sending an ECHO REQUEST packet out to seek an ECHO response. The name of the ECHO REQUEST packets shows exactly what they do — they test if the target IP address can receive and send back a reply, to test reachability.

Irrespective of some higher protocols like SMTP (email — traditionally a TCP/IP service on port 25) or HTTP (web — traditionally a TCP/IP service on port 80), ping tests if the IP address itself is reachable. No code has to be running a mail server or a web server; if the host implements the IP protocol fully, then it can reply to an ICMP message inside its network code.

Well, normally it can. There are all sorts of reasons why an ICMP packet might not be received or replied to, not the least of which is that firewall vendors sometimes assume ICMP is unsolicited traffic and drop it. Or, ISPs who are tired of customers endlessly testing if the link works, might drop it or deprioritize it. This has the amusing consequence that gamers — who often use ping to detect if they are a short distance from the game server that translates directly into “I can make my online player react faster than yours because my packets get to the server before yours” — often wind up with a faulty diagnostic of ‘distance’ because the ICMP packets have been sent on a slower path than normal to avoid the burdens of handling ICMP.

But ICMP is about a lot more than just echo and response. It can be used to push back on too much traffic, request a router, and give rich responses about why IP isn’t flowing end-to-end. This, in turn, demands that an ICMP packet be able to carry extra information. That ability to add ‘payload’ to an ICMP packet, and how it’s done is the root cause of this vulnerability.

In this case, the problem is that the implementation of ICMP allowed a stack overflow to take place. A stack overflow is when a piece of code refers to data held in a region of computer memory for a running a process called a ‘stack’ and the process can be fooled into thinking the stack includes memory that is actually allocated to another purpose.

Imagine the stack is a list of 100 places in memory, and a request is made for region 999. That’s clearly more than 100, so ideally stack logic would refuse to fetch it, or write to it but that’s not what sometimes happens. A stack overflow is when a computer is tricked into writing or reading outside the region delineated as a stack.

Reading is bad enough, it means an attacker can see things in memory they aren’t meant to. It might even mean being able to see things like passwords or security tokens in clear text. But, being able to write to memory illegally, a computer’s function can be altered from a distance, for example be made to run unintended instructions, or write its normal instructions with modified data. This, in turn, can lead to ‘privilege escalation’ where the result of the stack overflow is the ability to run commands at a higher level of privilege. For example, a web server runs at a low privilege and is not normally allowed to write to the filesystem outside it’s own boundaries or see processes run by other users, so if the stack overflow leads to privilege escalation, then the process can see things it shouldn’t and possibly alter their run state.

In a worst-case scenario, privilege escalation can lead to gaining access to the system with superuser privileges, called getting ‘root access’.

The vulnerability in CVE-2022-23093 is using ICMP to send data, which causes the receiving system to write up to 40 bytes of data outside of the stack region, using the space in the ICMP packet to specify the contents of the 40 bytes. So, it’s a remotely executed packet, which causes the receiving system to overwrite 40 bytes. It’s not directly causing a problem, but the 40-byte ‘hole’ would permit a well-crafted attacker to leverage other shortcomings, for example two other CVE in a linux system to gain access. A reassuring email to the FreeBSD-security list is confident this bug cannot be used to perform the same exploit on FreeBSD due to differences in the stack model.

This article explains in more detail and shows how the FreeBSD community has already responded with patching. It notes the exploit was confined to a restricted mode of operation in the machine called ‘capsicum’ sandboxing.

The FreeBSD security advisory is also well worth reading.

OpenBSD also had some consideration of the problem, this brief note on the OpenBSD journal notes the discovery of a bug in their implementation of ping from use of the ‘fuzzing’ technique.

This isn’t the first time ping has been exploited to wreak havoc. The so-called ‘PING OF DEATH‘ in the late 1990s is one of the reasons ICMP packets have been so heavily filtered by home routers and firewall systems. It is a little surprising that after all this time ping is still capable of being exploited and this vulnerability exists. That it took so long to be found shows just how complicated it is to defend against a motivated attacker — any weakness, even if it’s only 40 bytes long, is going to be exploited.

ICMP is important, and it would hurt the network more to completely ignore it or remove it than to remediate this kind of problem. Let’s hope there aren’t too many more attacks like this lurking out there.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.