# CVE-2020-15999: FreeType Heap Buffer Overflow in Load_SBit_Png
*Sergei Glazunov, Project Zero (Originally posted on [Project Zero blog](https://googleprojectzero.blogspot.com/p/rca.html) 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](https://bugs.chromium.org/p/project-zero/issues/detail?id=2103).

**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](CVE-2020-17087.md)) on Windows,
 - together with a Chrome-specific heap buffer overflow ([CVE-2020-16010](CVE-2020-16010.md)) in the browser process on Android.

## The Exploit

(The terms *exploit primitive*, *exploit strategy*, *exploit technique*, and *exploit flow* are [defined here](https://googleprojectzero.blogspot.com/2020/06/a-survey-of-recent-ios-kernel-exploits.html).)

**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](CVE-2020-17087.md) on Windows and [CVE-2020-16010](CVE-2020-16010.md) 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.

### 0-day detection methods

## Other References