Details on a (not so recent now) stack-based buffer overflow in the Adobe CFF rasterizer in FreeType2 (CVE-2014-2240, CVE-2014-9659)
This blog has experienced a long time of inactivity, as I’ve recently used it only to publish slides from conferences I presented at, with many months-long breaks in between. I am planning to change things up and start posting again in the upcoming weeks, starting with this blog post, which I originally wrote in early 2014. I haven’t posted it back then, as the bug in the FreeType project discussed here motivated me to look at other implementations of PostScript fonts and CharStrings specifically, which eventually resulted in an extensive research, dozens of bugs fixed by Microsoft, Adobe and Oracle, five long blog posts on the Google Project Zero blog (see the “One font vulnerability to rule them all” series), two nominations, and one Pwnie award. I didn’t want to spoil too much of what I was working on, and then just forgot about the post, but now that things have settled down on the font security front and I’m reactivating the blog, it is finally ready to go. Enjoy, and keep in mind the tenses in the article are used as if it was still 2014. :-) Some new parts I’ve added while dusting off the text are written in orange.
The bug was also briefly discussed during my last year’s 44CON presentation, see here.
At Google, we perform fuzz testing of a number of software targets: web browers, plugins, document viewers, open-source programs, libraries and more. A number of instances of our fuzzing efforts and their results have been documented in the past, see e.g. the “PDF fuzzing and Adobe Reader 9.5.1 and 10.1.3 multiple critical vulnerabilities”, “PDF Fuzzing Fun Continued: Status Update” or recent “FFmpeg and a thousand fixes” blog posts. One of the targets we have spent a lot of time on is FreeType2, a popular open-source library written in C, designed for high quality font rendering. The library is used in many commonly used operating systems and applications, such as GNU/Linux (and other Unix derivatives like FreeBSD and NetBSD), iOS, Android or ChromeOS, and hence is a valuable target for attackers seeking to exploit any of the aforementioned platforms.
The Google Security Team has always recognized the necessity for secure and robust font rendering libraries, which otherwise have been subject to frequent vulnerability hunting performed by various entities. Over the last decade, many dozens of vulnerabilities have been identified, fixed and publicly disclosed in the Windows subsystems (both kernel and user-mode) responsible for handling font files, for example:
- Font Rasterizer Local Elevation of Privilege Vulnerability (CVE-2007-1213)
- Embedded OpenType Font Integer Overflow Vulnerability (CVE-2010-1883)
- TrueType Font Parsing Vulnerability (CVE-2012-0159)
- Win32k Font Parsing Vulnerability (CVE-2013-1291)
- Uniscribe Font Parsing Engine Memory Corruption Vulnerability (CVE-2013-3181)
- ~25 vulnerabilities reported in the Windows Kernel, DirectWrite and .NET by yours truly in 2014 and 2015 (list).