CVE-2020-17087: Windows pool buffer overflow in cng.sys IOCTL

This page has been moved to our new site. Please click here to go to the new location.

Posted by Mateusz Jurczyk, Project Zero (2021-02-04)

Disclosure or Patch Date:

• Disclosure: 30 October 2020 by Google Project Zero
• Patch Date: 10 November 2020

Product: Microsoft Windows

Advisory: https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-17087 

Affected Versions: For Windows 10 2004, KB4579311 and previous

First Patched Version: For Windows 10 2004, KB4586781

Issue/Bug Report: https://bugs.chromium.org/p/project-zero/issues/detail?id=2104 

Patch CL: N/A

Bug-Introducing CL: N/A

Proof-of-Concept: https://bugs.chromium.org/p/project-zero/issues/detail?id=2104 
Exploit Sample: N/A

Access to the exploit sample? Yes

Reporter(s): Mateusz Jurczyk and Sergei Glazunov of Google Project Zero

Bug Class: Buffer overflow

Vulnerability Details: Pool buffer overflow due to an incorrect 16-bit integer truncation in the processing of IOCTL 0x390400. The bug is in the function cng!CfgAdtpFormatPropertyBlock. To calculate the size of the buffer to allocate, the function multiplies an attacker-controlled integer by 6 and stores the result in a variable of type USHORT. If the input buffer length passed in during the IOCTL call is greater than or equal to 0x2AAB, then the buffer allocated by BCryptAlloc() will be too small, leading to a buffer overflow.

Exploit method: The exploit uses the buffer overflow to establish an arbitrary read/write primitive in the kernel address space with the help of Named Pipe objects.

How do you think you would have found this bug? Either through a manual audit of the IOCTL handling code accessible from user-mode, or through (coverage-guided) fuzzing.

(Historical/present/future) context of bug: The vulnerability was used as part of an exploit chain for Chrome on Windows. It allowed the attacker to break out of the Chrome sandbox and execute code with system privileges.

Areas/approach for variant analysis:

• Look for other trivial cases of an allocation size being down-casted to a smaller integer type in cng.sys and other drivers with user-reachable attack surfaces.

Found variants: N/A

Structural improvements: High level ideas:

• Use static analysis to identify places in the kernel code where inadequately small integer types are used to store buffer lengths, and refactor them or discourage their use in the future.
• Potential further hardening of the kernel pool allocator to make the exploitation of memory corruption in the Windows kernel (especially large overflows that corrupt more than 64 kB) less reliable.

Potential detection methods for similar 0-days: Directly interacting with the cng.sys driver without going through system APIs is unusual, and may be an indicator of active exploitation.

Other references: N/A