Attacker Value
High
(6 users assessed)
Exploitability
Low
(6 users assessed)
User Interaction
None
Privileges Required
None
Attack Vector
Adjacent_network
29

CVE-2020-16898 aka Bad Neighbor / Ping of Death Redux

Disclosure Date: October 16, 2020
Add MITRE ATT&CK tactics and techniques that apply to this CVE.
Initial Access
Techniques
Validation
Validated
Validated

Description

A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets. An attacker who successfully exploited this vulnerability could gain the ability to execute code on the target server or client.

To exploit this vulnerability, an attacker would have to send specially crafted ICMPv6 Router Advertisement packets to a remote Windows computer.

The update addresses the vulnerability by correcting how the Windows TCP/IP stack handles ICMPv6 Router Advertisement packets.

Add Assessment

5
Ratings
Technical Analysis

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.

4
Ratings
Technical Analysis

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

3
Ratings
Technical Analysis

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.

2
Ratings
  • Exploitability
    Very Low
Technical Analysis

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.

CVSS V3 Severity and Metrics
Base Score:
8.8 High
Impact Score:
5.9
Exploitability Score:
2.8
Vector:
CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Attack Vector (AV):
Adjacent_network
Attack Complexity (AC):
Low
Privileges Required (PR):
None
User Interaction (UI):
None
Scope (S):
Unchanged
Confidentiality (C):
High
Integrity (I):
High
Availability (A):
High

General Information

Vendors

  • microsoft

Products

  • windows 10 1709,
  • windows 10 1803,
  • windows 10 1809,
  • windows 10 1903,
  • windows 10 1909,
  • windows 10 2004,
  • windows server 2016 1903,
  • windows server 2016 1909,
  • windows server 2016 2004,
  • windows server 2019 -
Technical Analysis

Update October 16, 2020: Security company Quarkslab published an analysis and crash proof-of-concept (PoC) for CVE-2020-16898. The crash PoC has been verified by independent researchers.

Description

On Tuesday, October 13, as part of the October 2020 Patch Tuesday release, Microsoft published a security advisory for CVE-2020-16898, a remote code execution (RCE) vulnerability in the Windows TCP/IP stack. The vulnerability arises when the TCP/IP stack does not properly handle ICMPv6 Router Advertisement packets. Successful exploitation requires sending specially-crafted ICMPv6 Router Advertisement packets to a remote Windows computer and could give an attacker the ability to execute code on the target server or client. CVE-2020-16898 carries a CVSSv3 base score of 9.8.

There are no reports of exploitation in the wild as of October 13, 2020, though Microsoft’s advisory rates the vulnerability as “exploitation more likely.” The vulnerability has garnered broad attention as potentially wormable.

Security firm McAfee has a great technical analysis of CVE-2020-16898 available here, which we highly recommend reading. See below for our own analysis.

Affected products

  • Windows 10 Version 1709 for 32-bit Systems
  • Windows 10 Version 1709 for ARM64-based Systems
  • Windows 10 Version 1709 for x64-based Systems
  • Windows 10 Version 1803 for 32-bit Systems
  • Windows 10 Version 1803 for ARM64-based Systems
  • Windows 10 Version 1803 for x64-based Systems
  • Windows 10 Version 1809 for 32-bit Systems
  • Windows 10 Version 1809 for ARM64-based Systems
  • Windows 10 Version 1809 for x64-based Systems
  • Windows 10 Version 1903 for 32-bit System
  • Windows 10 Version 1903 for ARM64-based Systems
  • Windows 10 Version 1903 for x64-based Systems
  • Windows 10 Version 1909 for 32-bit Systems
  • Windows 10 Version 1909 for ARM64-based Systems
  • Windows 10 Version 1909 for x64-based Systems
  • Windows 10 Version 2004 for 32-bit Systems
  • Windows 10 Version 2004 for ARM64-based Systems
  • Windows 10 Version 2004 for x64-based Systems
  • Windows Server 2019
  • Windows Server 2019 (Server Core installation)
  • Windows Server, version 1903 (Server Core installation)
  • Windows Server, version 1909 (Server Core installation)
  • Windows Server, version 2004 (Server Core installation)

Rapid7 analysis

Exploit development and weaponization of CVE-2020-16898 would be non-trivial. Security firms have been quick to point out that exploiting the vulnerability to crash a target system with a Blue Screen of Death (BSoD) is straightforward; while that’s a good coal-mine canary, a full exploit chain would require an additional primitive (e.g., an info leak) to function fully. Hypothetically, the “easiest” exploit chain might be one in which an attacker leverages a different vulnerability to obtain the randomized kernel base address and stack cookie to reliably exploit CVE-2020-16898.

In general, reproducing a crash is to code execution as the tip of the iceberg is to the whole: A crash is an important first step on the path to successful exploit development, but turning even the heartiest BSoD into reliable and weaponizable RCE is a significant technical hurdle, especially for vulnerabilities whose immediate exploitability is hampered by modern software stack mitigations (e.g., kernel ASLR). Overall, Rapid7 researchers hesitate to add our voices to the chorus of commentators insisting that exploits are a short way away.

The likelihood of reliable exploits for CVE-2020-16898 may be less important than the fact that a single maliciously-crafted packet has the potential to knock out an entire network segment, which is problematic even before considering the possibility of code execution on the target system.

Guidance

We recommend applying the patch for CVE-2020-16898 as soon as possible. For those who are unable to patch immediately, consider disabling ICMPv6 RDNSS as a workaround (only available for Windows 1709 and above) via the PowerShell command below:
netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable

See Microsoft’s advisory for further details. No reboot is needed after making the change.

McAfee’s threat detection team also has detection logic and a Suricata rule available here.