Whitebox can be a risk in an enterprise network. But how much? Tom Hollingsworth was a guest on the Heavy Networking podcast to talk whitebox, disaggregration, and more. You can hear the full episode, Heavy Networking 542: Is Whitebox Too Risky For The Enterprise?, right here: https://packetpushers.net/podcast/heavy-networking-542-is-whitebox-too-risky-for-the-enterprise/ You can subscribe to the Packet Pushers’ […]
What is the 2020 Ping of Death?
Ping of Death vulnerabilities are nothing new. These vulnerabilities arise from issues in memory allocation in the TCP/IP stack. If memory is improperly allocated and managed, a buffer overflow vulnerability can be created that leaves the application vulnerable to exploitation.
The original Ping of Death was discovered in 1997 and was the result of an implementation error in how operating systems handled IPv4 ICMP packets. ICMP ECHO_REQUEST packets (aka ping) are intended to be 64 bytes, but this length was not enforced. Any ping packet with a length greater than 65536 bytes (the expected maximum value of the length field) would cause a system to crash.
In August 2011, Microsoft fixed another Denial of Service in its TCP/IP Stack that occurred when processing a sequence of specially crafted Internet Control Message Protocol (ICMP) messages
In August 2013, a third ping of death vulnerability was announced and patched in the Windows operating system. This time it was specific to the IPv6 protocol.
Yesterday (October 2020), Microsoft revealed its second IPv6 Ping of Death vulnerability as part of its October Patch Tuesday release. Exploitation of this vulnerability could allow an attacker to perform a Denial of Service attack against an application and potentially achieve remote code execution.
2020 Ping of Death Technical Details
The Ping of Death vulnerability arises from an issue in how Microsoft’s tcpip.sys implements the Recursive DNS Server (RDNSS) option in IPv6 router advertisement packets. This option is intended to provide a list of available recursive DNS servers.
The issue that creates the Ping of Death vulnerability is that tcpip.sys does not properly handle the possibility that the router advertisement packet contains more data than it should. Microsoft’s implementation trusts the length field in the packet and allocates memory accordingly on the stack.
An unsafe copy of data into this allocated buffer creates the potential for a buffer overflow attack. This enables the attacker to overwrite other variables on the stack, including control flow information such as the program’s return address.
How the Vulnerability Can Be Exploited
In theory, the buffer overflow vulnerability can be exploited to achieve a couple of different goals:
- Denial of Service: Exploitation of the buffer overflow vulnerability enables “stack smashing” that can crash the application.
- Remote Code Execution: Using return-oriented programming, a buffer overflow exploit could cause a function to return to and execute attacker-provided shellcode.
In practice, a Denial of Service attack is the most likely use for this exploit. In order to perform a successful Denial of Service attack, all an attacker needs to do is attempt to write outside of the memory accessible to it (triggering a segmentation fault) or to overwrite a critical value within the program stack.
One of these key values is the stack canary, which is also one of the reasons why exploitation of this vulnerability is unlikely to allow RCE. A stack canary is a random value placed on the stack that is designed to detect attempts to overwrite the function return address via a buffer overflow attack. Before attempting to return from a function (by going to the location indicated by the return address), a protected program checks to see if the value of the stack canary is correct. If so, execution continues. If not, the program is terminated.
The existence of a stack canary makes it more difficult to exploit the vulnerability for RCE, and the use of Address Space Layout Randomization (ASLR), which makes functions useful to attackers harder to locate in memory, exacerbates this issue. However, it is possible to bypass both of these protections in certain cases, so an exploit may be developed that enables the 2020 version of the ping of death to be used for RCE. If this is the case, the repercussions could be severe as tcpip.sys is a kernel-level module within the Windows operating system.
Ping of Death in the Wild
A patch for this vulnerability was included in the October 2020 Patch Tuesday release of updates. At the time, the vulnerability was not publicly disclosed, meaning that (theoretically) no one knew about it previously and could develop an exploit.
Based on the Microsoft description of the vulnerability, a Proof of Concept for using it for a DoS attack has already been created. Additionally, the vulnerability has been given an exploitability value of 1, meaning that it is very likely to be exploited but has not yet been observed in the wild.
This means that we can expect to see DoS attacks using this vulnerability shortly, and the potential exists that an attacker will successfully create a RCE exploit using it as well. If this is the case, the wormability of the exploit makes it likely to be used to spread ransomware and similar malware (like Wannacry and EternalBlue).
Protecting Against the 2020 Ping of Death
The vulnerability in tcpip.sys was patched in an update included in the October 2020 Patch Tuesday release. Installing this update will fix the vulnerability and protect a system from exploitation.
Beyond installing the update, it is a good idea to minimize your attack surface by disabling unnecessary functionality. If you currently do not use the functionality, then disabling IPv6 in general or RDNSS in particular can eliminate the potential exploitability of this and any other vulnerabilities within the Microsoft implementation of this functionality. Instructions for doing so are included in Microsoft’s description of the vulnerability.