Year: 2016

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 3^rd 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.

Read more

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 menu):

• Windows Core System Calls: 32-bit and 64-bit.
• Windows Graphical System Calls: 32-bit and 64-bit.

After a few years of inactivity in this area, I’ve found some time to update and thoroughly refresh the tables. The changelog is as follows:

1. Added information from Windows Server 2003 (R2, R2 SP2), Windows Server 2008 (R2, R2 SP1), Windows Server 2012 (R2) and Windows 10 (1507, 1511, 1607).
2. Clarified some versions of Windows, resulting in removing non-existent Windows Server 2008 SP1 (32-bit), Windows XP SP0 (64-bit), Windows Server 2003 SP1 (64-bit), Windows Server 2008 SP1 (64-bit).
3. Removed empty columns with missing information from the win32k 32-bit table.
4. 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”.
5. Unified the layout of NT and win32k tables.
6. Added more granular information to the win32k 64-bit table (accounting for all service packs and major releases).
7. 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.

Read more

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 9^th 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].

Read more

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.

Read more