Skip to content

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).

Continue reading ›

44CON slides and details about further Windows kernel font vulnerabilities are out

Since my last blog post and the REcon conference in June, I have continued working on font security, especially in the area of Windows kernel and font engines derived from the Adobe Type Manager Font Driver. More specifically, I moved from manually auditing PostScript Charstring implementations to running automated fuzz-testing of the overall font-handling code; after all, font files are so much more than just the glyph outline programs. The Windows kernel fuzzing initiative started in May this year and has already resulted in having 7 OpenType (ATMFD.DLL) and 4 TrueType (win32k.sys) security issues fixed in the operating system in the August Patch Tuesday. Details of the vulnerabilities are now publicly available in the google-project-zero bug tracker:

  1. Windows Kernel win32k.sys TTF pool-based buffer overflow in the IUP[] program instruction (CVE-2015-2455)
  2. Windows Kernel ATMFD.DLL OTF pool-based buffer overflow with malformed GPOS table (CVE-2015-2426)
  3. Windows Kernel win32k.sys TTF pool-based buffer overflow in win32k!scl_ApplyTranslation (CVE-2015-2456)
  4. Windows Kernel ATMFD.DLL OTF out-of-bounds reads from the input CharString stream (CVE-2015-2458)
  5. Windows Kernel ATMFD.DLL OTF invalid memory access due to malformed CFF table (CVE-2015-2459)
  6. Windows Kernel ATMFD.DLL OTF invalid memory access due to malformed CFF table (CVE-2015-2460)
  7. Windows Kernel ATMFD.DLL OTF write to uninitialized address due to malformed CFF table (CVE-2015-2432)
  8. Windows Kernel ATMFD.DLL OTF out-of-bounds read due to malformed Name INDEX in the CFF table (CVE-2015-2461)
  9. Windows Kernel ATMFD.DLL OTF out-of-bounds read due to malformed FDSelect offset in the CFF table (CVE-2015-2462)
  10. Windows Kernel win32k.sys TTF out-of-bounds pool memory access in win32k!fsc_RemoveDups (CVE-2015-2463)
  11. Windows Kernel win32k.sys TTF out-of-bounds pool write in win32k!fsc_BLTHoriz (CVE-2015-2464)

Interestingly enough, two of the vulnerabilities turned out to have collided with the work of other, external researchers: CVE-2015-2426 (.OTF bug) was also discovered in the leaked Hacking Team data dump and subsequently fixed by Microsoft in an out of band security bulletin on 20 July 2015 (MS15-078), while CVE-2015-2455 (.TTF bug) was found and successfully exploited by the Keen Team during the pwn2own competition this year.

Just last week I had the pleasure to attend the 44CON conference in London, and give a talk called “Reverse engineering and exploiting font rasterizers: the OpenType saga”. The presentation was divided into three chapters, discussing an interesting FreeType vulnerability in a CFF rasterizer contributed by Adobe (an arbitrary out-of-bounds stack-based write access) and how it was incorrectly patched the first time, then explaining the details of the Charstring vulnerabilities in ATMFD and its derivatives fixed in March and May, and finally outlining my recent fuzzing activity and its results. The slide deck can be found below for your amusement:

Reverse engineering and exploiting font rasterizers: the OpenType saga (PDF, 8.69MB)

Lastly, during the course of the last few weeks I have published several posts on the official Google Project Zero blog. The first four of them make a sort of a whitepaper accompanying the REcon slides, as they discuss the discovery and exploitation process of the BLEND vulnerability, providing some further context and historical background for the curious:

  1. One font vulnerability to rule them all #1: Introducing the BLEND vulnerability
  2. One font vulnerability to rule them all #2: Adobe Reader RCE exploitation
  3. One font vulnerability to rule them all #3: Windows 8.1 32-bit sandbox escape exploitation
  4. One font vulnerability to rule them all #4: Windows 8.1 64-bit sandbox escape exploitation

More recently, I have also described the exploitation of a universal OpenType memory disclosure vulnerability affecting the Windows kernel (ATMFD), DirectWrite, Adobe Reader (CoolType), WPF and Oracle Java, on the example of Internet Explorer, one of DirectWrite’s users:

  1. Enabling QR codes in Internet Explorer, or a story of a cross-platform memory disclosure

And that’s it! I hope you enjoy reading the posts as much as I enjoyed working on them, and stay tuned for more font-related disclosures soon!

Results of my recent PostScript Charstring security research unveiled

Some months ago, I started reverse engineering and investigating the security posture of the Adobe Type Manager Font Driver (ATMFD.DLL) module, which provides support for Type 1 and OpenType fonts in the Windows kernel since Windows NT 4.0, and remains there up to this day in Windows 8.1. Specifically, I focused on the handling of so-called “Charstrings”, which are essentially binary encoded PostScript programs with a dedicated set of instructions and a specific execution environment, responsible for drawing the shape of each glyph at a particular point size. It didn’t take long to notice several important points:

  • The overall code quality of the Charstring interpreter function in ATMFD.DLL was badly low, with some bugs being clearly visible in the code at first glance. This implied that (surprisingly, considering the seemingly large amount of attention received from the security community) I entered a completely unexplored territory that others haven’t delved into, or at least publicly.
  • The kernel module used the same interpreter for both Type 1 (Type 1 fonts) and Type 2 (OpenType/CFF fonts) Charstrings, and supported every single feature that has ever been part of the specification, and plenty of undocumented ones as well – bloating the size of the function to more than 20kB (!) on the x86 platform.
  • As a result of historically strong collaboration between vendors in the early days of digital font development (the 80’s and mostly 90’s), various modern font engines have a common ancestor in Adobe’s implementation of Type 1 / OpenType fonts, including:
    • Windows GDI (i.e. ATMFD.DLL in the Windows kernel),
    • Adobe Reader (i.e. the CoolType library),
    • Microsoft DirectWrite (a library used by Internet Explorer, Google Chrome, Mozilla Firefox etc.),
    • Windows Presentation Foundation.

The above observations led me to believe that the code could be affected by one or more critical vulnerabilities, and that some of those vulnerabilities could be shared across multiple widespread desktop products, additionally elevating the potential impact of any such discovery. After several weeks of reverse engineering and auditing the interpreter for vulnerabilities, I have ended up with multiple low to critical severity issues, with most of the serious ones reproducing in more than one font engine. I subsequently reported all of my discoveries to the respective vendors (Microsoft and Adobe), which fixed the bugs in security bulletins MS15-021 (March), APSB15-10 (May) and  MS15-044 (May). A quick summary of the research results is shown below, with links pointing to the corresponding google-security-research bug tracker entries, containing reports with detailed analysis of the vulnerabilities together with Proof of Concept files, as they were provided to the vendors:

Microsoft Windows (ATMFD) Adobe Reader (CoolType) DirectWrite Windows Presentation Foundation
Unlimited Charstring execution CVE-2015-0074
Out-of-bounds reads from the Charstring stream CVE-2015-0087 CVE-2015-3095
Off-by-x out-of-bounds reads/writes relative to the operand stack CVE-2015-0088
Memory disclosure via uninitialized transient array CVE-2015-0089 CVE-2015-3049 CVE-2015-1670 CVE-2015-1670
Read/write-what-where in LOAD and STORE operators CVE-2015-0090
Buffer overflow in Counter Control Hints CVE-2015-0091 CVE-2015-3050
Buffer underflow due to integer overflow in STOREWV CVE-2015-0092 CVE-2015-3051
Unlimited out-of-bounds stack manipulation via BLEND operator CVE-2015-0093 CVE-2015-3052

While many of the above issues had the potential to be usable in the context of remote code execution (Adobe Reader, Windows kernel) or elevation of privileges (Windows kernel) attacks, one particular vulnerability stood out from the others, as it provided a specially crafted font with the ability to operate on any data on the thread’s stack with all instructions available in the Type 1 / Type 2 Charstring instruction set (including arithmetic, logic, conditional, and other instructions). In other words, one could reliably generate a full ROP chain on the stack within the PostScript program, with no external interaction other than loading the font in the first place.

The extremely powerful primitive provided by the vulnerability, together with the fact that it affected all supported versions of both Adobe Reader and Microsoft Windows (32-bit) – thus making it possible to create an exploit chain leading to a full system compromise with just a single bug – makes it one of the most interesting security issues I have discovered so far. Considering that 64-bit builds of Windows were not affected by that particular bug, I also devised a x64 way to achieve reliable elevation of privileges using another Charstring vulnerability (CVE-2015-0090) found during the research, which also adheres to the “100% reliability” and “all mitigations bypassed” philosophy. Since the overall exploitation process was also quite challenging and required the use of several interesting tricks, I decided to discuss it at the REcon security conference in Montreal in a talk called “One font vulnerability to rule them all: A story of cross-software ownage, shared codebases and advanced exploitation”. As I presented the research two days ago, I am now publishing the corresponding slide deck:

One font vulnerability to rule them all: A story of cross-software ownage, shared codebases and advanced exploitation (PDF, 7.78MB)

Below you can see videos showing successful exploitation of Adobe Reader 11.0.10 using the BLEND vulnerability (CVE-2015-3052), accompanied by sandbox escapes via ATMFD.DLL in the Windows Kernel, using again the BLEND vulnerability on x86 builds (CVE-2015-0093) and a “Registry Object” vulnerability on x64 builds (CVE-2015-0090).

If you are interested in font vulnerability research, be sure to keep an eye out on this and the Google Project Zero blogs, as further technical posts and/or whitepapers regarding this effort will be published there in the near future.

Insomni’hack 2015, presentation slide deck and CTF results

(Collaborative post by Gynvael Coldwind and Mateusz “j00ru” Jurczyk)

Just three days ago another edition of the great Insomni’hack conference held in Geneva came to an end. While the event was quite short, lasting for just one day, it featured three tracks of security talks, including some very interesting ones such as Automotive security by Chris Valasek, or Copy & Pest – A case-study on the clipboard, blind trust and invisible cross-application XSS by Mario Heiderich. This year we were also invited to the conference to talk about CTF techniques, experiences and entertaining tasks encountered by the Dragon Sector team we lead and actively play in. We thus gave a presentation called Pwning (sometimes) with style – Dragons’ notes on CTFs, and are now making the slide deck publicly available for your enjoyment:

Pwning (sometimes) with style – Dragons’ notes on CTFs (3.86MB, PDF)

While the conference was very well organized and had many interesting talks, the main event of the evening was only about to start at 18:00 – the CTF competition organized by the Insomni’hack crew, which attracted hundreds of players from all around the world, including many top teams from the CTF scene (e.g. StratumAuhuur, int3pids, dcua, penthackon, 0x8F). Since we really liked the finals from last year, Dragon Sector also came back in a large squad of 9 players; one of whom played in a different team due to a strict 8-person limit. We did our best to defend last year’s title (top 1) and eventually succeeded, but it was not an easy task for sure. The most intense moment was when the StratumAuhuur team submitted a flag 4 minutes before the end of the CTF (at 3:56:23 AM), closing our point advantage to only ~20 points, which was so close that it could have easily changed in favor of Stratum regardless of our actions (due to this year’s variable nature of tasks scoring, which accounted for the total number of teams solving each challenge). Fortunately, Gynvael and I were on a verge of solving another networking task at the time and barely managed to get it a little more than a minute before the end of the competition, consequently securing a win. The situation is well illustrated in the photo of the final ranking on the right.

The organizers, SCRT, have also published their own summary of the CTF with a full ranking and some interesting stats: Insomni’hack finals – CTF results.

SECURE 2014 slide deck and Hex-Rays IDA Pro advisories published

Yesterday I gave a talk at a Polish security conference held in Warsaw, Poland, called “Ucieczka z Matrixa: (nie)bezpieczna analiza malware” (eng. “Escaping the Matrix: (in)secure malware analysis”). The presentation was lightly technical and concerned the different threats of using popular software to aid in interacting with and analyzing malware samples. While the talk was prepared entirely in Polish, most of the slides should be easily understandable by English speakers, and Google Translate works pretty well, so I decided to share them here anyway:

secure.pdf (3.85 MB)

A part of the presentation was dedicated to multiple memory corruption Hex-Rays IDA Pro vulnerabilities I discovered earlier this year (see the product Changelog). Below you will find the original reports I sent to the vendor in September:

  • [COFF] [DBG] Heap Memory Corruption due to Integer Underflow.
  • [EPOC] 4-Byte Heap Buffer Overflow due to an Off-By-One in bounds checking.
  • [DEX] Heap Buffer Overflow due to Integer Overflow.
  • [PEF] Multiple (4) instances of Heap Buffer Overflows due to integer problems.
  • [PEF] Heap Memory Corruption due to logical bugs in memory management.
  • [UNIVERSAL] Heap Buffer Overflows due to logical bugs in memory management (BADMEMSIZE constant), exploitable via multiple file formats on Linux.

Download: (1.71 MB)

Kudos to Ilfak Guilfanov and Hex-Rays for a very quick turnaround (less than two weeks from sending the reports to releasing bugfixes) and running the Bug Bounty Program! Keep up the good work!

CONFidence 2014 slides from Dragon Sector are now available

(Collaborative post by Gynvael Coldwind and Mateusz “j00ru” Jurczyk)

Just yesterday another edition of the largest and most successful IT security conference held in Poland – CONFidence – ended. The Dragon Sector CTF team (which we founded and are running) actively participated in the organization of the event by hosting an onsite, individual CTF for the conference attendees and giving a talk about the most interesting challenges we have solved so far in our not too long CTF career.

The final standings of the CONFidence 2014 CTF can be found below. We will also publish a more detailed summary, together with some or all of the challenges, on our official Dragon Sector blog within a few days.

The slide deck from our presentation can be found below: On the battlefield with the Dragons – the interesting and surprising CTF challenges (3.93MB, PDF).


A case of a curious LibTIFF 4.0.3 + zlib 1.2.8 memory disclosure

As part of my daily routine, I tend to fuzz different popular open-source projects (such as FFmpeg, Libav or FreeType2) under numerous memory safety instrumentation tools developed at Google, such as AddressSanitizer, MemorySanitizer or ThreadSanitizer. Every now and then, I encounter an interesting report and spend the afternoon diving into the internals of a specific part of the project in question. One such interestingly-looking report came up a few months ago, while fuzzing the latest LibTIFF (version 4.0.3) with zlib (version 1.2.8) and MSan enabled:

MemorySanitizer report for a corrupted TIFF file processed by LibTIFF

This post outlines the details of this low severity, but nevertheless interesting issue.

Continue reading ›

FFmpeg and a thousand fixes

(Collaborative post by Mateusz “j00ru” Jurczyk and Gynvael Coldwind; a short version is available at the Google Online Security blog).

Following more than two years of work, the day has finally came – the FFmpeg project has incorporated more than a thousand fixes to bugs (including some security issues) we have discovered in the project thus far:

$ git log | grep Jurczyk | grep -c Coldwind

As this event clearly marks an important day in our ongoing fuzzing effort, we decided to provide you with some background on one of the activities we are currently working on.

Continue reading ›

Windows System Call and CSR API tables updated

Having the first spare weekend in a really long time, I have decided it was high time to update some (all) of the tables related to Windows system calls and CSR API I once created and now try to maintain. This includes NT API syscalls for the 32-bit and 64-bit Intel platforms, win32k.sys syscalls for 32-bit and 64-bit Intel platforms, as well as CSR API information formatted in two different ways for convenience (a list and a table). Without further ado, all of the tables now contain up-to-date data covering all operating systems available to me at the time, including Windows 8, 8.1 and Server 2012. The links are as follows:

NT system calls

Win32k.sys system calls

CSR API calls

Pointers to all tables can also be found in the left pane under the “OS Structures” section. If you spot a bug in any of the tables or have any other comments, let me know. I hope you find them useful!

ZeroNights 2013 and NTVDM vulnerabilities

Just yesterday I had the pleasure to speak at a highly hacking-oriented Russian conference, ZeroNights, for the second time (see my “ZeroNights slides, Hack In The Box Magazine #9 and other news” post from last year). The conference itself has been great so far – several interesting and inspiring talks, lots of leet Russian hackers and the Moscow atmosphere makes it a truly unique event. The title of my talk was “Windows Kernel Trap Handler and NTVDM Vulnerabilities — Case Study”, and as the name suggests, it included coverage of four vulnerabilities in all 32-bit Windows kernels starting from Windows NT 3.1 through Windows 8/Server 2012, making them 20 year old issues now. Namely, the following problems were discussed:

  • CVE-2013-3196 (nt!PushInt write-what-where condition)
  • CVE-2013-3197 (nt!PushException write-what-where condition)
  • CVE-2013-3198 (nt!VdmCallStringIoHandler write-where condition)
  • 0-day (nt!PushPmInterrupt and nt!PushRmInterrupt Blue Screen of Death DoS)

All of the above security flaws were local problems (i.e. require the ability to execute arbitrary code on the victim machine); the first three have a maximum impact of elevation of privileges (ring-0 code execution) and thus were fixed by Microsoft in September this year by the MS13-063 security bulletin. While equally interesting, the fourth one only makes it possible to get the kernel to reference memory at addressess 0xfff80008 through 0xffffffff (top 128 pages of the kernel address space) which, given the memory layout used by the operating system, is believed to be non-exploitable at the time of this writing. The bugcheck triggered by the condition is as follows:

TRAP_FRAME:  88c37b90 -- (.trap 0xffffffff88c37b90)
ErrCode = 00000000
eax=00000000 ebx=00000002 ecx=7fff0000 edx=fffffeff esi=88c37d34 edi=fff80008
eip=82b31e51 esp=88c37c04 ebp=88c37c50 iopl=0         nv up ei ng nz na pe cy
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010287
82b31e51 668b07          mov     ax,word ptr [edi]        ds:0023:fff80008=????
Resetting default scope

The slide deck can be downloaded here (zeronights.pdf, 6.9MB).