Abstract

The tcpip.sys windows driver’s IppSendError and IppSendErrorList had a bug which led to integer overflow -> heap-based buffer overflow and if you are able to get the memory addresses through ICMP echo you are able to perform RCE. This vulnerability was dicovered in August and was patched in mid August. Here, I have referred the detailed article from malwaretech and POC from ynwarcs and recreated the vulnerability using metasplotable3 and kali linux.

IPv6 Extension Header:

  • Extension Headers in IPv6: IPv6 uses extension headers to handle optional internet-layer information. These headers are processed sequentially, unlike IPv4 where options are usually confined within the main header. When a packet includes multiple extension headers (like Hop-by-Hop Options, Routing, or Fragment headers), they need to be processed one by one in the order they appear.
  • Packet Objects in a Linked List: During the processing of these extension headers, packet objects are structured in a linked list. A linked list is a data structure where each element (or “node”) contains a reference (or “link”) to the next element. In the context of packet processing, each packet object corresponds to a segment of the network packet and is linked to the next object representing the subsequent part of the data stream.
  • NET_BUFFER Object: Each packet object includes a NET_BUFFER object. The NET_BUFFER is a structure used to handle packet data, which contains information such as the start of the buffer, the current position being processed, and how much data has been parsed.
  • Offset 0x30 and Current Offset Field: At an offset of 0x30 within the NET_BUFFER, there is a field called the “current-offset” field. This field keeps track of how far the packet has been parsed during processing.
  • Current Offset Value of 0x28: When processing begins, particularly during the examination of extension headers, the current-offset is typically set to 0x28. This value indicates that the initial IPv6 header (which is 40 bytes or 0x28 in size) has been parsed, but no further processing has occurred on the subsequent headers or payloads. The parsing hasn’t progressed beyond the basic IPv6 header, so at this stage, none of the extension headers have been processed yet.
  • Parsing Progress: As parsing continues, this offset will increase, reflecting the cumulative length of the IPv6 header and any processed extension headers. This allows the packet processor to keep track of which parts of the packet have been analyzed and which parts still need to be addressed.

How does the exploit work:

  1. We send the malformed packet in fragments in huge quantity. 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.
  2. 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.
  3. 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).
  4. 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.

Exploit:

  1. 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.
  2. 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).
  3. 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.
  4. 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.
  5. To trigger Ipv6pReassemblyTimeout, the sender of the fragment has to be inactive for 1 minute. Our strategy is then:
  6. 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
  7. Cause the underflow in Ipv6pReceiveFragment and create a new reassembly object with fragment data length that’s a high 16-bit value
  8. Wait 1 minute without sending any more packets so that Ipv6pReassemblyTimeout is triggered.
  9. Cause an integer overflow in buffer size calculation in Ipv6pReassemblyTimeout and trigger a heap-based buffer overflow.
  10. The packets in the script are spammed so that there’s a higher chance of them being coalesced. The main payload is pretty simple:
  11. 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
  12. 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).

References:

That is all folks !! ☺️