Analysis performed using tcpip.sys from Windows 10 v1909 x64 (sha256: f2a0cb717ccbe7e7ff93ccadaeb23df4a8a76b386b6623fee1b5a975c3f16bfa)

Overview

A crafted IPv6 Router Advertisement frame can a stack based buffer overflow due to an improper calculation of the RDNSS
(type 25) option. When an RDNSS option uses a crafted length with an even value the parser will interpret the last 8
bytes of it as the start of the next option. When combined with fragmentation, this can cause a overflow due to the size
of the mis-interpreted header not being validated.

Exploitability Analysis

The public PoCs reliably reproduce this vulnerability to trigger a bug check condition. The relevant function is
tcpip!Ipv6pHandleRouterAdvertisement which handles the parsing logic and is the function whose local variable is
overflown. The public PoCs use a Route Information (type 24) option to actually perform the overflow. In this case the
actual overflow is performed by a call to NdisGetDataBuffer at Ipv6pHandleRouterAdvertisement+0xb8a01.

In this call, the third parameter Storage is a pointer to the stack at location rbp+0xb8. From the documentation:

(Storage is) a pointer to a buffer, or NULL if no buffer is provided by the caller. The buffer must be greater than or
equal in size to the number of bytes specified in BytesNeeded . If this value is non-NULL, and the data requested is
not contiguous, NDIS copies the requested data to the area indicated by Storage.

Since Storage is non-NULL, non-contiguous (due to the packet fragmentation), it is used as a destination buffer and
wOptLength bytes are copied to it. In this context, wOptLength is the length of the option in the original data
times 8. With a length of 176 (field value 0x16), the stack cookie at offset rbp+0x260 will be overwritten. As the
function returns, this leads to a Bug Check when the stack cookie is checked at
tcpip!Ipv6pHandleRouterAdvertisement+0x10e0. The value of the stack cookie is also XORed with the value of the stack
pointer (rsp) so knowing the value would not be sufficient to replace it in the overwrite.

After the overflow operation has taken place, the loop continues to process the following options:

• Type 3 (Prefix Information)
  
• Type 24 (Route Information)
  
• Type 25 (RDNSS)
  
• Type 31 (DNS Search List Option)
  

(see: http://blog.pi3.com.pl/?p=780)

From the /GS (Buffer Security Check) documentation:

A vulnerable parameter is allocated before the cookie and local variables. A buffer overrun can overwrite these
parameters. And code in the function that uses these parameters could cause an attack before the function returns and
the security check is performed.

After inspecting the logic for each of the four types that will be processed, there were no identified references to
values which could be controlled by an attacker using the overflow. While the handler for the Prefix Information (type

1. option uses a 32 byte buffer which could be controlled by the attacker starting at rbp+0x200, it is memset to
   zero at Ipv6pHandleRouterAdvertisement+0xa19.
   

There are no other references to the space between rbp+0x1b8 (&Storage) and rbp+0x260 (the stack cookie) that are
accessible from this late in the Ipv6pHandleRouterAdvertisement function.

An alternative vector could potentially utilize a Search List (type 31) option to trigger the overflow. This function
makes a similar call to NdisGetDataBuffer with a location on the stack. In this case the attacker can overflow the
buffer starting at rbp+0x90 and overwrite the stack cookie at rbp+0x190. This function is less interesting as there
appear to be no usable references before the return and there is no looping logic due to the handler and overflow being
a subroutine of Ipv6pHandleRouterAdvertisement.

Rating high based on Microsoft’s published information. No user interaction required, no authentication required, and allows RCE with crafted ICMPv6 router advertisement packet

Not going to repeat anything that other users have contributed here but one thing I think that was missed from the original advisory that I didn’t see noted here is that ICMPv6 is not routeable over the internet, and instead only over the local subnet (see the line This vulnerability is not routable over the internet, but only over a local subnet. under the Mitigations section of https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2020-16898).

This means that at best you could only exploit this if you were on the same network as the attacker. Even then this is a NULL pointer dereference vulnerability and all of the affected versions of Windows 10, as well as the affected server versions don’t allow you to map the NULL page needed to turn this into a remotely exploitable vulnerability unless you already have local access to the system (and if you already have local access, then why are you using this vulnerability anyway? There are better alternatives :) ).

A great indepth writeup of this vulnerability can be found at https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/ which covers the exploit in detail along with how it was patched.

If you want to test if systems are affected there is now working BSoD code at https://github.com/0vercl0k/CVE-2021-24086 if you need to check if a system is vulnerable and don’t mind BSoD’ing the target.

Since this bug was released a couple months ago, I haven’t seen any sources that have indicated there’s been in-the-wild exploitation. Typical notes on memory corruption vulnerabilities being difficult to weaponize as reliable RCE apply here.