CVE-2024-38063 : A Deep Dive Into Remote Code Execution In tcpip.sys

This is a (rather flaky) poc for CVE-2024-38063, a RCE in tcpip.sys patched on August 13th 2024. I didn’t find and report this vuln, that would be Wei.

Requirements

pip3 install scapy

pip3 install scapy

python3 cve-2024-38063.py

The easiest way to reproduce the vuln is by using bcdedit /set debug on on the target system and restarting the machine/VM.

This makes the default network adapter driver kdnic.sys, which is very happy to coalesce packets.

If you’re trying to reproduce the vuln on a different setup, you’ll need to get the system in a position where it will coalesce the packets you sent. You can read the troubleshooting section below on more details.

Rough RCA

You can read this great analysis of the vulnerability by Marcus if you’re interested in the technical details. The details I’ve written below are meant to serve as a summary, rather than serious technical analysis.

• In certain situations, windows will coalesce multiple IP packets together and batch process them.
  • It processes the extension headers in each packet first, and only then moves on to process the data in each packet.
• During extension header processing, packet objects of these coalesced packets are linked together in a linked list. Each packet object contains a NET_BUFFER object which contains buffered packet data.
  • At offset 0x30 we also have a current-offset field which indicates how far the packet has been parsed. At this stage, the offset value will generally be 0x28, indicating that the IPv6 header has been parsed but nothing else.
• When processing the “destination options” extension header in tcpip!Ipv6pReceiveDestinationOptions, a parsing error will result in tcpip!IppSendErrorList being called. This function calls tcpip!IppSendError on each packet object in the linked list (starting from the current one).
• Under certain conditions (e.g. if the packet is unicast), tcpip!IppSendError has side effects. It “reverts” the buffered packet data back to the start and resets the current-offset field to zero.
• However, in this whole chain of events, only the first packet is marked as having an error (offset 0x8C).
  • This means that the driver will continue to parse extesion headers of other packets in the linked list, even if they’ve been “reverted” in IppSendError.
• The processing of those packets that have been reverted is then done with unexpected data: the buffered packet data is pointing towards the beginning of the packet (i.e. the IPv6 header) rather than to the extension headers, and the offset field value is zero rather than 0x28.

For more information click here.