During the past few weeks, I travelled around the world to give talks at several great security conferences, such as Ruxcon (Melbourne, Australia), PacSec (Tokyo, Japan), Black Hat Europe (London, UK) and finally Security PWNing Conference (Warsaw, Poland). At a majority of the events, I presented the results of my Windows Metafile security research, which took place earlier this year and yielded vulnerabilities in GDI (exploitable e.g. in Internet Explorer), GDI+ (e.g. Microsoft Office), ATMFD.DLL (Windows local privilege escalation) and the Virtual Printers mechanism in VMware Workstation. As part of the talks, I explained what GDI and metafiles really are, the process I followed while hunting for and identifying the vulnerabilities, and the exploitation paths for some of them. Finally, I discussed my approach to fuzzing a user-mode Windows DLL module on Linux machines (cross-platform), on the example of a 3rd party JPEG2000 decoder used in VMware products. Since my allocated time slots at both Ruxcon and PacSec were too short to cover the entirety of the material, I talked about the ATMFD.DLL vulnerabilities exclusively at Ruxcon, and about GDI+ only at PacSec. A complete list of the EMF bugs that were mentioned in the presentations can be found in the Google Project Zero tracker.

The second talk (presented at BH) focused purely on fuzzing and the various thoughts, techniques and results I arrived at after actively using this approach to uncover software security flaws for more than 5 years, both as part of and outside of work. The topics included gathering initial corpora of input files, extracting code coverage information from running programs, using this information to “distill” and manage live corpora (using a parallelized algorithm), interacting with our target application on various levels, and effectively mutating the input data to accomplish the best results. The presentation was then concluded with a brief analysis of my recent Windows kernel font fuzzing initiative, which has resulted in the discovery of 18 issues so far.

In this post, I would like to publicly announce both slide decks used in the above talks. While some of the conferences have already made them available on their corresponding websites, the slides linked here include some further fixes and improvements, and specifically the EMF ones are all combined into a single PDF file, forming a self-contained source of information about all the discovered bugs. Enjoy, and as always, feel free to send questions, comments and suggestions.

Those of you interested in the Windows kernel-mode internals are probably familiar with the syscall tables I maintain on my blog: the 32-bit and 64-bit listings of Windows system calls with their respective IDs in all major versions of the OS, available here (and are also linked to in the left menu):

Performed a major clean up of the lists, resolving all syscall handler collisions and renaming invalid symbols (e.g. “FsRtlSyncVolumes”) stemming from compiler optimizations to their correct form. From now on, all system calls are represented by their real names starting with “Nt”.

Unified the layout of NT and win32k tables.

Added more granular information to the win32k 64-bit table (accounting for all service packs and major releases).

Fixed HTML syntax errors and improved JavaScript code formatting.

I hope the tables keep proving useful for Windows researchers interested in those interfaces. :-) And of course, all comments, suggestions and bug reports are highly appreciated!

In the previous blog post, I discussed a modest technique to “fix” the default process heap in order to prevent various Windows API functions from crashing, by replacing the corresponding field in PEB (Process Environment Block) with a freshly created heap. This of course assumes that the attacker has already achieved arbitrary code execution, or is at least able to use ROP and knows the base addresses of some vital system DLLs. It is likely the last exploitation technique one would use before gaining full control over the vulnerable application or system, and was indeed used by Gynvael and me while wrapping up the exploitation of the easier challenge during this year’s DEF CON CTF qualifiers which took place in May.

However, before we could even reach that stage, I had to overcome a few other significant obstacles, the hardest of which was converting the available primitives into a hijacked control flow. Following hours of trying to reproduce the same heap layout on the organizers’ and my own platform (exploiting the bugs was in fact the easiest part), I finally managed to achieve close to arbitrary memory read and write capabilities. By that point, I knew the location of the heap, the challenge image base and NTDLL.DLL image base, where I could freely read from and write to. On the other hand, the task itself did not make it easy to get controlled EIP even with such powerful primitives, as it didn’t store plain-text function pointers, virtual objects or any data directly controlling the execution flow on either the heap or in static memory. This meant that a generic technique had to be used instead.

All of the ideas I tested throughout Day 2 of the competition fell through. The CRT-related function pointers in static memory I could potentially overwrite were encoded with the EncodePointer API. There were some vtable pointers on the heap used during program termination, but I was unable to get them positioned in a similar fashion both locally and remotely, and I strived to write an exploit that I could test in both environments (a fellow CTF player – Dougall – didn’t care and just blindly exploited the bug on the task server). I had a pretty decent idea centered around a list of destructor pointers saved in NTDLL, but in a last attempt to find a simpler and more elegant solution, I decided to check if the stack address couldn’t be somehow leaked from heap, which I could read without any limits.

In theory, storing stack addresses on the heap doesn’t make any sense. The heap is designed for long-lasting allocations that can be passed between various execution contexts within a single process (functions, threads etc.), while stack objects are only valid for the duration of a function execution (or even shorter). Thus, we should not typically observe any stack addresses placed on the heap, or else they would indicate some very poor programming practices. However, Windows is a complex system full of unexpected quirks, so there might still be many non-obvious reasons for such behavior, and all I really needed was a single stack address at a roughly consistent position on the heap. With this assumption, I wrote the following simple program to scan through the entire default process heap in search of the desired addresses:

During the weekend of May 21-23 (directly after the CONFidence CTF that we organized with Dragon Sector), qualifications to the famous DEF CON CTF 2016 took place. We obviously participated in what is probably the most binary heavy, challenging and competitive CTF of the year, eventually ending up 9th on the final scoreboard, which was sufficient to get us qualified to the main event. :-)

While the competition featured a great number of tasks to solve, including multiple pwnables in the CGC (Cyber Grand Challenge) formula, I must admit that I spent nearly the entire CTF working on a single challenge: a vulnerable Windows x86 executable called easier, authored by Thing2. After two full days of hacking by myself, and developing a ROP chain together with Gynvael for the last few hours, we managed to get the flag just in time – roughly 25 minutes before the end of the CTF. Overall, the problem was the second with fewest successful solves (completed by a total of 5 teams – PPP, DEFKOR, 9447, Samurai and Dragon Sector), and considering that it was available since the start of the contest (contrary to secrfrevenge), it was probably the most difficult challenge of all.

The source code of the task is available on LegitBS’ github: here. If you are interested in reading a complete (but quite different than ours) solution of the 9447 team, check out the following article: Def Con Quals 2016 – Easier [Pwnable].

The CTF challenge

For some basic context, the task was a very small executable, with DEP and ASLR enabled, running on Windows Server 2012 (Amazon EC2) under AppJailLauncher. It used symmetric encryption with a static key for communication, and allowed the network client to perform 8 operations, all centered around a list of allocations on the heap. There were plenty of vulnerabilities, or at least code constructs which appeared as such, but turned out to be unusable in practice. This made me wonder if I was missing something, the author was trolling hard, or if they just didn’t sufficiently test the task. Now I know it wasn’t #1 (since other players had the same thoughts), but I still don’t know which of options #2 and #3 it is. :)

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:

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:

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:

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:

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:

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:

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:

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:

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.

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 securityby 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:

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.

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:

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.

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.