j00ru//vx tech blog

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

• Windows X86 System Call Table (NT/2000/XP/2003/Vista/2008/7/8)
• Windows X86-64 System Call Table (NT/2000/XP/2003/Vista/2008/7/2012/8)

Win32k.sys system calls

• Windows WIN32K.SYS System Call Table (NT/2000/XP/2003/Vista/2008/7/8)
• Windows x86-64 WIN32K.SYS System Call Table (NT/2000/XP/2003/Vista/2008/7/2012/8)

CSR API calls

• Windows CSRSS API List (NT/2000/XP/2003/Vista/2008/7/2012/8)
• Windows CSRSS API Table (NT/2000/XP/2003/Vista/2008/7/2012/8)

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!

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 (zeronights.pdf, 6.9MB).

Enjoy!

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:

Read more

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

Read more

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!

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.

Read more

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

It was six weeks ago when we first introduced our effort to locate and eliminate the so-called double fetch (e.g. time-of-check-to-time-of-use during user-land memory access) vulnerabilities in operating system kernels through CPU-level operating system instrumentation, a project code-named “Bochspwn” as a reference to the x86 emulator used (bochs: The Open Source IA-32 Emulation Project). In addition to discussing the instrumentation itself in both our SyScan 2013 presentation and the whitepaper we released shortly thereafter, we also went to some lengths trying to explain the different techniques which could be chained together in order to successfully and optimally exploit kernel race conditions, on the example of an extremely constrained win32k!SfnINOUTSTYLECHANGE (CVE-2013-1254) double fetch fixed by Microsoft in March 2013.

The talk has yielded a few technical discussions involving a lot of smart guys, getting us to reconsider several aspects of race condition exploitation on x86, and resulting in plenty of new ideas and improvements to the techniques we originally came up with. In particular, we would like to thank Halvar Flake (@halvarflake) and Solar Designer (@solardiz) for their extremely insightful thoughts on the subject. While we decided against releasing another 70 page long LaTeX paper to cover the new material, this blog post is to provide you with a thorough follow-up on efficiently winning memory access race conditions on IA-32 and AMD64 CPUs, including all lessons learned during the recent weeks.

Please note that the information contained in this post is mostly relevant to timing-bound kernel security issues with really small windows (in the order of several instructions) and vulnerabilities which require a significant amount of race wins to succeed, such as limited memory disclosure bugs. For exploitation of all other problems, the CPU subtleties discussed here are probably not quite useful, as they can be usually exploited without going into this level of detail.

All experimental data presented in this post has been obtained using a hardware platform equipped with an Intel Xeon W3690 @3.47GHz CPU (with Hyper-Threading disabled) and DDR3 RAM, unless stated otherwise.

Read more

Another week, another conference. Just a few days ago, Gynvael and I had the pleasure to attend and present at the CONFidence 2013 infosec conference traditionally held in Cracow, Poland. The event requires no further introduction – it has been simply the best Polish conference in the security area since it first started, and this year’s edition was up to the usual high standard – we had some great time, meeting old and making new friends as well as enjoying some of the better talks.

With regards to our presentation, we originally intended it to be a gathering of references concerning all of the interesting quirks, undocumented behavior and other amusing facts (directly or indirectly related to the CPU architecture) that we heard or learnt about in both 32 and 64-bit x86 processors during the recent years. If you are closely following the CPU hacking and operating system security scene, you are probably aware of most of the material we presented – still, we hope it proves useful as a thorough reference and possibly motivates you to take a deeper look at some of the areas we discussed during the talk. In addition to what was covered on stage, you can also find several extra “further reading” slides containing references to information which did not fit into the elementary slide deck.

Download: Beyond MOV ADD XOR – the unusual and unexpected in x86 (PDF, 5.6MB)

Other than that, I also presented at a local Polish SEConference event in Cracow a few days earlier, using my NoSuchCon 2013 slide deck translated to Polish:

Download: Bezpieczeństwo jądra Windows, lub jak zabić system dwiema instrukcjami (PDF, 4.3MB)

That’s about it, have fun!

The first edition of the NoSuchCon security conference held in Paris ended just a few days ago. Before anything else, I would like to thank all of the organizers (proudly listed at nosuchcon.org) for making the event such a blast! Both the location, venue and speaker line-up were amazing, with lots of free beer and wealth of people to chat with. Overall, I am very happy to have shown up there and I will definitely make sure to attend the second edition of the conference.

Other than drinking, discussing 0-days and visiting Paris, I also had the pleasure to give a talk about the usual subject – Windows kernel security. The exact title of my presentation was “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions“, and touched on the subject of several different exploitation techniques, internal CPU related behavior and security vulnerabilities (all related to the Windows operating system) that I discovered during the course of last several weeks / months.

While the slide deck was made available to the attendees right at the beginning of my talk at nosuchcon.org/talks (great idea!), I’m reposting them here anyway, in case you haven’t had a chance to take a look yet. In fact, a majority of the talks were interesting and highly technical, so be sure to check the available material for all presentations ;-)

Slides: “Abusing the Windows Kernel: How to Crash an Operating System With Two Instructions” (3.3MB, PDF)

KiTrap0e advisory: “Abusing Windows NT #PF Trap Handler to Bugcheck and Leak Information”

Read more

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

A few days ago we (Gynvael and I) gave a talk during the SyScan’13 conference in the fine city of Singapore, and as promised (though with a slight delay), today we are publishing both the slide deck and a white paper discussing memory access pattern analysis – a technique we recently employed with success to discover around 50 double-fetch vulnerabilities in Windows kernel and related drivers (Elevation of Privileges and Denial of Service class; see Microsoft Security Bulletins MS13-016, MS13-017, MS13-031 and MS13-036 released in February and April this year. Also, stay tuned for more security patches in May and June).

In our SyScan presentation, we explained the concept of kernel race conditions in interacting with user-mode memory, gave a brief rundown on how they can be identified by using CPU-level instrumentation of an operating system session, and later focused on how they can be successfully exploited with the help of several generic techniques (on the example of three Windows vulnerabilities discovered by the Bochspwn project). While we only had the time to go through a single case study (the CVE-2013-1254 vulnerability in win32k!SfnINOUTSTYLECHANGE), both slides and the paper contain a detailed analysis of another local privilege escalation: CVE-2013-1278 in nt!ApphelpCacheLookupEntry, and an amusing case of a double fetch behavior (it is not clear if it can be classified as a bug) found in the default kernel implementation of the standard nt!memcmp function, as a bonus.

We hope you will enjoy both the slides and whitepaper – considering the amount of time we have dedicated to the research, we would really appreciate your feedback.

Download:

• Slides: “Bochspwn: Exploiting Kernel Race Conditions Found via Memory Access Patterns” (2.6MB, PDF)

• Paper: “Identifying and Exploiting Windows Kernel Race Conditions via Memory Access Patterns” (1.0MB, PDF)

Read more