Comprehensive Breakdown of CVE-2024-38063: A Critical Threat in the Windows TCP/IP Stack

CVE-2024-38063 is a Windows TCP/IP stack critical vulnerability with a 9.8 CVSS score, affecting the processing of IPv6 packets. Remote attackers can exploit this vulnerability using an integer underflow when handling IPv6 extension headers to execute malicious code or cause a DoS (Denial of Service).

Since IPv6 is enabled by default on most modern systems, this zero-click flaw poses a substantial risk. As a result, all unpatched versions of Windows 10, Windows 11, and Windows Server 2008, 2012, 2016, 2019, and 2022 with IPv6 enabled are vulnerable to this CVE.

The Windows TCP/IP stack is a foundational operating system component responsible for network communication via the Transmission Control Protocol/Internet Protocol (TCP/IP) suite. It handles all network interactions, facilitating communication between devices across local and global networks.

IPv6 was developed to address the limitations of IPv4. It introduced various enhancements, such as modularity and flexibility through extension headers. The headers, positioned between the IPv6 header and the payload, support optional data and advanced features.

Key IPv6 extension headers include:

• Hop-by-Hop Options (Next Header = 0) 
• Routing Header (Next Header = 43) 
• Fragment Header (Next Header = 44) 
• Destination Options Header (Next Header = 60) 
• Authentication Header (AH) (Next Header = 51) 
• Encapsulating Security Payload (ESP) (Next Header = 50) 

Each extension header points to the next via the Next Header field, creating a sequential chain. This modularity introduces complexity to the packet-handling process and potential exploitation vectors.

An integer underflow occurs when a computation produces a smaller value than the minimum representable value for a data type. For instance, subtracting a larger value from a smaller one to an unsigned integer can cause the result to become a very large positive value.

An integer overflow happens when the value exceeds the maximum limit of the data type and "overflows" back to the minimum representable value (e.g., 0 in a 0-10 range). Both scenarios happen due to improper handling of boundary conditions in arithmetic operations, leading to severe vulnerabilities in software systems.

After receiving an IPv6 packet, Windows first parses the IPv6 header. Then, the IppReceiveHeaderBatch function checks the value of the Next Header field to choose the appropriate handler for the subsequent headers. For each extension header in the chain, IppReceiveHeaderBatch invokes the corresponding routine to process that specific header.

Microsoft’s patch to address the CVE-2024-38063 vulnerability was thoroughly examined by security researcher Marcus Hutchins. His technical blog offers detailed insights into the root cause of this vulnerability. Building on his findings, our fellow has further explored the issue to gain a thorough understanding of the exploit.

Integer Underflow in Fragment Processing

By setting the Next Header field to 44, indicating a Fragment Header, a packet gets handled by IPv6 fragmentation or reassembly routines. When the packet reaches the fragment parser, Ipv6pReceiveFragment(), it specifies that: 

• The packet size is zero. 
• The fragment header indicates that additional data remains to be processed. 

In the Ipv6pReceiveFragment() function, the allocation size for fragment_size is computed as subtracting 0x30 (packet header length) from the packet size without any validation. If the packet size is zero, this subtraction underflows, resulting in a large 16-bit value (around 0xFFD0 or 65488), causing the parser to process an excessive memory outside the packet's valid boundaries and leading to memory corruption. 

From Underflow to Overflow and Mismatch in Allocation

The Ipv6pReassemblyTimeout() function is responsible for cleaning up incomplete IPv6 fragments after a specified time using 16-bit arithmetic to determine buffer sizes and copy operations. Due to the underflow in the previous step, where the packet_length or the fragment_size becomes 0xFFD0, an overflow occurs during allocation.  

The resulting calculation causes the register to reset to zero, leading to the allocation of only 48 bytes of memory. However, because the amount of data copied (65,488 bytes from reassembly->payload) does not correspond to the allocated memory, a controllable buffer overflow occurs in the kernel pool. 

In an attempt to reproduce the CVE-2024-38963 vulnerability, our fellows crafted a series of malformed packets designed to exploit the flaw. The process they followed was:

Insert an IPv6 Destination Options extension header (type 60) following the base IPv6 header, then embed an invalid option (e.g., option type 0x81). 

This manipulation forces the Windows kernel (tcpip.sys), to set always_send_icmp = true, triggering ICMPv6 error generation via the IppSendErrorList() routine.

Flooding the target with rapid bursts of these malformed packets increased the chances of the kernel to group multiple packets into a single Net-Buffer List (NBL). When two or more packets are grouped, the vulnerable IppSendErrorList() loop gets activated, incorrectly resetting the DataLength and Offset metadata in subsequent fragments (packet size is now zero). 

Following the transmission of malformed packets, fragmented IPv6 packets that include Fragment extension headers are sent. These fragments are processed using the already corrupted DataLength values. 

The kernel holds fragments for 60 seconds (managed by Ipv6pReassemblyTimeout) to allow packet reassembly. During this timeout, the corrupted DataLength values trigger an integer underflow in Ipv6pReceiveFragment, resulting in an incorrectly calculated (excessively large) fragment size.

The kernel allocates a heap buffer based on the underflowed values. Two different calculations occur during the reassembly process: one determines the memory allocation size (which, due to a 16-bit overflow, becomes too small), and the other calculates the copy length using the large, underflowed value.

This mismatch leads to an out-of-bounds write, causing a heap-based buffer overflow that can be exploited to trigger a Denial-of-Service (DoS) or Remote Code Execution.