Skip to content

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:

Ucieczka z Matrixa.pptx (3.96 MB)
Ucieczka z Matrixa.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: ida6.6_bugs.zip (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).

Enjoy!

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
1120

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
nt!PushPmInterrupt+0x20c:
82b31e51 668b07          mov     ax,word ptr [edi]        ds:0023:fff80008=????
Resetting default scope

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

Enjoy!

Windows win32k.sys menus and some “close, but no cigar” bugs

Welcome after one of the more lengthy breaks in the blog’s activity. Today, I would like to discuss none other than several interesting weaknesses around the implementation of menus (like, window menus) in the core component of the Microsoft Windows kernel – the infamous win32k.sys driver, also known as the “Java of Windows” in terms of overall security posture.

Now, menus have been a part of the Windows graphical interface since the very beginning of the operating system existence. The implementation became part of the Windows kernel at the time of porting a majority of the Windows manager (User) subsystem to a ring-0 component during Windows NT 4.0 development. The functionality consists of user-facing (i.e. the NtUserThunkedMenuInfo and NtUserThunkedMenuItemInfo system calls) and rendering portions of code; I have found several bugs or problems in both areas.

First of all, let’s start with the win32k!xxxSetLPITEMInfo function, which can be generally reached through the two following call chains in Windows 7 x86:

NtUserThunkedMenuItemInfo → xxxInsertMenuItem → xxxSetLPITEMInfo
or
NtUserThunkedMenuItemInfo → xxxSetMenuItemInfo → xxxSetLPITEMInfo

The routine itself is responsible for setting up an ITEM structure, which describes a single menu item and is defined as follows for the previously stated platform:

Continue reading ›

Black Hat USA 2013, Bochspwn, slides and pointers

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

Two weeks ago (we’re running late, sorry!) Gynvael and I had the pleasure to attend one of the largest, most technical and renowned conferences in existence – Black Hat 2013 in Las Vegas, USA. The event definitely stood up to our expectations – the city was purely awesome (especially for someone who just turned 21 like me), the venue was at least as great, we saw many interesting and truly inspiring talks and a whole bunch of old friends, not to mention meeting a fair number of new folks. In addition to all this, our visit to Vegas turned out quite successful for other reasons too – our “Identifying and Exploiting Windows Kernel Race Conditions via Memory Access Patterns” work was nominated and eventually awarded a Pwnie (in fact, two mascots) in the “Most Innovative Research” category. Woot!

While the subject of memory access pattern analysis or the more general kernel instrumentation was only mentioned briefly when we originally released the first slide deck and whitepaper, as we mostly focused on the exploitation of constrained local kernel race conditions back then, our most recent Black Hat “Bochspwn: Identifying 0-days via System-Wide Memory Access Pattern Analysis” talk discussed the specifics of how the control flow of different operating systems’ kernels can be logged, examined or changed for the purpose of identifying various types of local vulnerabilities. Demos were presented live and are not available publicly (especially considering that one of them was a 0-day).

Slides: “Bochspwn: Identifying 0-days via System-Wide Memory Access Pattern Analysis” (5.26MB, PDF)

Continue reading ›

Approaching BlackHat US 2013 and new Dragon Sector blog

This is a quick reminder that Gynvael and I are going to attend BlackHat US 2013 in Las Vegas next week with the “Bochspwn: Identifying 0-days via System-Wide Memory Access Pattern Analysis” presentation on the second day of the event. The talk is going to largely extend our previous performance at SyScan this year (see blog post), detailing the implementation of our “Bochspwn” project, discussing other approaches to system-wide instrumentation and how it can be effectively used to discover different local vulnerability classes (not just double fetches!) in widely used kernels. We will also provide a follow up on using Bochspwn against open-source platforms (Linux, FreeBSD, OpenBSD), including extensive coverage of our findings there, and last but not least, we will release the Bochs instrumentation toolkit as an open-source project for everyone to hack on. If you happen to be in the Sin City at the time, don’t hesitate to come by and say hi! See you there!

If you are not going to make it this time, expect the presentation slide deck shortly after the conference.

In other news, our CTF team called “Dragon Sector” has recently started their own blog: http://blog.dragonsector.pl/. The website is supposed to feature write-ups from the more interesting CTF tasks we manage to solve during the competitions. With merely four posts so far, the blog is surely going to fill up with interesting posts as we play contests in the near future, so be sure to keep an eye on it.

Cheers!

Changing the cursor shape in Windows proven difficult by NVIDIA (and AMD)

If you work in the software engineering or information security field, you should be familiar with all sorts of software bugs – the functional and logical ones, those found during the development and internal testing along with those found and reported by a number of complaining users, those that manifest themselves in the form of occassional, minor glitches in your system’s logic and those that can lose your company 440 million US dollars in 30 minutes; not to mention bugs which can enable attackers to remotely execute arbitrary code on your computer without you even realizing it. While the latter type of issues is usually of most interest to security professionals and 0-day brokers (not all developers, though) and thus the primary subject of this blog, this post is about something else – the investigation of a non-security (and hardly functional) bug I originally suspected win32k.sys for, but eventually discovered it was a problem in the NVIDIA graphics card device drivers.

My frequently used window order, with vim present in the background.

Figure 1. My typical work window order, with vim present in the background.

To give you some background, I am a passionate user of vim for Windows (gvim, specifically). When working with code, my usual set up for one of the monitors is a black-themed vim window set for full-screen, sometimes with other smaller windows on top when coding happens to be preempted with some other tasks. The configuration is illustrated in Figure 1 in a slightly smaller scale. A few weeks ago, I noticed that moving the mouse cursor from the vim window over the border of the foreground window (Process Explorer in the example) and inside it, the cursor would be occassionally rendered with colorful artifacts while changing the shape. Interestingly, these artifacts would only show up for a fraction of second and only during one in a hundred (loose estimate) hovers from vim to another window. Due to the fact that the condition was so rare, difficult to reproduce manually and hardly noticeable even when it occured, I simply ignored it at the time, swamped with work more important than some random pixels rendered for a few milliseconds once or twice a day.

Once I eventually found some spare time last week, I decided to thoroughly investigate the issue and find out the root cause of this weird behavior. I was primarily motivated by the fact that colorful artifacts appearing on the display could indicate unintended memory being rendered by the system, with the potential of pixels representing uninitialized kernel memory (thus making it a peculiar type of information disclosure vulnerability). Both me and Gynvael have found similar issues in the handling of image file formats by popular web browsers in the past, so the perspective of disclosing random kernel bytes seemed tempting and not too far off. Furthermore, I knew it was a software problem rather than something specific to one hardware configuration, as I accidentally encountered the bug on three different Windows 7 and 8 machines I use for my daily work.

Following a brief analysis, it turned out I was not able to reproduce the issue using any background window other than vim. While I started considering if this could be a bug in vim itself, I tested several more windows (moving the mouse manually for a minute or two) and finally found that the Notepad worked equally well in the role of a background. Not a vim bug, hurray!

As both windows share the same cursor shape while in edit mode – the I-beam, I concluded the bug must have been specific to switching from this specific shape to some other one. Precisely, while hovering the mouse over two windows and a boundary, the cursor switches from I-beam () to a horizontal resize () and later to a normal arrow (). Relying on the assumption that the bug is a race condition (or least timing related, as the problem only manifested while performing rapid mouse movements), I wrote the following proof of concept code to reproduce the problem in a more reliable manner (full source code here):

Continue reading ›