CVE-2020-16898 Windows TCP/IP Remote Code Execution Vulnerability
Virsec Security Research Lab Vulnerability Analysis
The Virsec Security Research Lab provides detailed analysis on recent and notable security vulnerabilities.
A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets, aka 'Windows TCP/IP Remote Code Execution Vulnerability'.
Watch the video to learn more about this and other important vulnerabilities.
The CVSS Base Score is 8.8 (High)
Win 10 all versions (July 29, 2015)
Windows Server 2019 (March 20, 2018)
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)
The earliest vulnerable Client version was released on 07/29/2015 and for Server OS was 03/20/2018. The exposure window is therefore over five and a half years for Client OS and two and a half years for Server OS.
This was disclosed by Microsoft in a security advisory.
Microsoft announced a critical vulnerability in the Windows IPv6 stack, which allows an attacker to send maliciously crafted packets to potentially execute arbitrary code on a remote system. The proof-of-concept shared with MAPP (Microsoft Active Protection Program) members is both extremely simple and perfectly reliable, hence it is available publicly. It results in an immediate BSOD (Blue Screen of Death), but more so, indicates the likelihood of exploitation for those who can manage to bypass Windows 10 and Windows Server 2019 mitigations.
The effects of an exploit that would grant remote code execution would be widespread and highly impactful, as this type of bug could be made wormable. For ease of reference, we nicknamed the vulnerability “Bad Neighbor” because it is located within an ICMPv6 Neighbor Discovery “Protocol”, using the Router Advertisement type.
A remote code execution vulnerability exists when the Windows TCP/IP stack improperly handles ICMPv6 Router Advertisement packets that use Option Type 25 (Recursive DNS Server Option) and a length field value that is even. In this Option, the length is counted in increments of 8 bytes, so an RDNSS option with a length of 3 should have a total length of 24 bytes. The option itself consists of five fields: Type, Length, Reserved, Lifetime, and Addresses of IPv6 Recursive DNS Servers. The first four fields always total 8 bytes, but the last field can contain a variable number of IPv6 addresses, which are 16 bytes each. As a result, the length field should always be an odd value of at least 3, per RFC 8106:
When an IPv6 host receives DNS options (i.e., RDNSS and DNSSLoptions) through RA messages, it processes the options as follows: The validity of DNS options is checked with the Length field; that is, the value of the Length field in the RDNSS option is greater than or equal to the minimum value (3) and satisfies the requirement that (Length - 1) % 2 == 0.
When an even length value is provided, the Windows TCP/IP stack incorrectly advances the network buffer by an amount that is 8 bytes too few. This is because the stack internally counts in 16-byte increments, failing to account for the case where a non-RFC compliant length value is used. This mismatch results in the stack interpreting the last 8 bytes of the current option as the start of a second option, ultimately leading to a buffer overflow and potential RCE.
Virsec Security Platform (VSP) Support
The Virsec Security Platform (VSP)-Host monitors processes that are spawned which are not part of a set of whitelisted process. Any attempt to execute new command or unknown binary would be denied by VSP-Host’s Process Monitoring capability.
Download the full vulnerability report to learn more about this and other important vulnerabilities.