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

usage

Modify the fields in the script:

• iface <- If you have multiple adapters, you need to choose which one to use to send packets. e.g. "eth0" on linux or "Hyper-V Virtual Ethernet Adapter" on windows. If you're going to use your default interface, leave it empty.
• ip_addr <- IP address of the target system (IPv6)
• num_tries & num_batches <- How many different packet batches to send. more of them = more heap corruptions caused + higher chance of triggering the vulnerability.
• mac_addr <- Leave empty, unless scapy complains it can't find the mac address. See below in troubleshooting.

Run the script:

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.

demo

cve-2024-38063.webm

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.

strategy

• To abuse the vulnerability, we make use of Ipv6pReceiveFragment. The function parses the fragment extension header and assumes that the offset field of the packet will be at least 0x28 when calculating the length of the non-header data in the packet by subtracting 0x30 from the current offset value. This value is then stored in the reassembly object whose purpose is to reassemble the fragmented packet.
• In our case, the function will be called on a packet that has been reverted by IppSendError. The offset value will be zero and increased to 8 somewhere earlier in Ipv6pReceiveFragment. When calculating the size of non-header data, the value will underflow and be equal to 0xffd8 (the subtraction is done in 16 bits).
• The length value is used in only two places later:
  • Ipv6pReassembleDatagram, where it's used to calculate the length of an output buffer of the reassembled packet. However, all calculations are done in 32-bits and there's a sanity check that the total length doesn't exceed 0xFFFF, which does happen in this case.
  • Ipv6pReassemblyTimeout, where it's also used in the same manner. However, the calculations here are done in 16 bits and an integer overflow happens. This leads to a buffer overflow when copying data into the buffer later.

To trigger Ipv6pReassemblyTimeout, the sender of the fragment has to be inactive for 1 minute. Our strategy is then:

• Send malformed destination options to trigger IppSendError, followed by a fragment packet
• Hope that the two packets are coalesced and that the second packet's object will have its data and offset reset
• Cause the underflow in Ipv6pReceiveFragment and create a new reassembly object with fragment data length that's a high 16-bit value
• Wait 1 minute without sending any more packets so that Ipv6pReassemblyTimeout is triggered.
• Cause an integer overflow in buffer size calculation in Ipv6pReassemblyTimeout and trigger a heap-based buffer overflow.

The packets in the script are spammed so that there's a higher chance of them being coalesced. The main payload is pretty simple:

• IPv6 packet with a "destination options" extension header with malformed options data that will trigger an error in parsing
• IPv6 fragment #1, that we hope will be concatenated to the first packet
• IPv6 fragment #2 (same id), that may also be concatenated to the first two, but its main purpose is to complete the 2nd fragment so that errors aren't thrown out in case normal processing happens

We also set the hop limit and flow label fields in the IPv6 header manually. Recall that the buffered packet data is reset because of the vulnerability. This means that, when processing the fragment packet, the IPv6 header will be interpreted as fragment header data. The hop limit field in the IPv6 header will be interpreted as one of the bits of the id field in the fragment header. By changing it, we ensure that we trigger the vulnerability for multiple different fragments and cause multiple different corruptions, increasing the chance of a crash (since this is a PoC after all). The flow limit field of the ip header will be interpreted as the offset & "more indicator" fields of the fragment header. By setting it to 1, we indicate that there's more headers to come (hence being able to trigger Ipv6pReassemblyTimeout later) and that offset is zero (since this is the first packet with such id that's arriving).