CVE-2020-15999: FreeType Heap Buffer Overflow in Load_SBit_Png
Sergei Glazunov, Project Zero (Originally posted on Project Zero blog 2021-02-04)
The Basics
Disclosure or Patch Date: 19 October 2020
Product: Google Chrome/ Freetype
Advisory: https://chromereleases.googleblog.com/2020/10/stable-channel-update-for-desktop_20.html
Affected Versions: 86.0.4240.80 and previous
First Patched Version: 86.0.4240.111
Issue/Bug Report:
- Project Zero: https://bugs.chromium.org/p/project-zero/issues/detail?id=2103
- Chromium: https://bugs.chromium.org/p/chromium/issues/detail?id=1139963
- FreeType: https://savannah.nongnu.org/bugs/?59308
Patch CL:
- Chromium: https://chromium.googlesource.com/chromium/src/third_party/freetype2.git/+/80389cab7f5823e7c3b3fe4190a7c337439317de
- FreeType: https://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/src/sfnt/pngshim.c?id=a3bab162b2ae616074c8877a04556932998aeacd
Bug-Introducing CL: http://git.savannah.gnu.org/cgit/freetype/freetype2.git/commit/?id=01705395b08167b654a24f26673ee6e75a84f2be
Reporter(s): Sergei Glazunov of Google Project Zero
The Code
Proof-of-concept: A font file which will reproduce the crash in an ASAN build is attached here.
Exploit sample: N/A
Did you have access to the exploit sample when doing the analysis? Yes
The Vulnerability
Bug class: Heap buffer overflow
Vulnerability details:
FreeType is a popular software development library used to render text onto bitmaps, and provides support for other font-related operations. The vulnerability exists in the function Load_SBit_Png
, which processes PNG images that are embedded into fonts. Load_SBit_Png
truncates the image height and width to 16-bit integers when calculating the bitmap size. This size is used to allocate the buffer. However, later the code passes the original 32-bit values for the height and width along with the allocated buffer to libpng for further processing. Therefore, if the original width and/or height are greater than 65535, the allocated buffer won’t be able to fit the bitmap.
Patch analysis: N/A
Thoughts on how this vuln might have been found (fuzzing, code auditing, variant analysis, etc.):
The issue is relatively straightforward to be found during a manual code review. It's also quite possible that it has been discovered as a result of variant analysis of https://bugs.chromium.org/p/project-zero/issues/detail?id=168.
(Historical/present/future) context of bug:
The vulnerability was used by the actor in two exploit chains:
- together with a OS kernel issue (CVE-2020-17087) on Windows,
- together with a Chrome-specific heap buffer overflow (CVE-2020-16010) in the browser process on Android.
The Exploit
(The terms exploit primitive, exploit strategy, exploit technique, and exploit flow are defined here.)
Exploit strategy (or strategies): Still under analysis
Exploit flow: Still under analysis
Known cases of the same exploit flow: Still under analysis
Part of an exploit chain? Yes, paired with CVE-2020-17087 on Windows and CVE-2020-16010 on Android. The attacker also had iOS
The Next Steps
Variant analysis
Areas/approach for variant analysis (and why):
Fuzzing for interoperability issues between FreeType and its dependencies (e.g., libpng).
Found variants: N/A
Structural improvements
The issue is a textbook buffer overflow, so while generic solutions like memory tagging apply, it's unlikely there's a potential structural improvement that's specific to the bug/area.