Month: December 2012

Microsoft addressed several Windows kernel vulnerabilities in the MS12-075 security bulletin released in November this year, some of them residing in every version of the win32k.sys driver shipped with the NT family line systems. Apart from the obviously extremely interesting remote web browser => ring-0 arbitrary code execution issue, there have also been two other Local Privilege Escalation bugs, at least one of which was directly related to the management of legacy 16-bit applications running within a VDM (Virtual DOS Machine). Since the topics of use-after-free vulnerabilities in the Windows kernel – and especially in old and poorly understood functionality – seems to be very appealing for most, this post aims to cover some of the technical details related to that particular security flaw. In addition to (hopefully) having some didactic and entertainment value, this write-up and the very existence of that bug illustrates how trivial it still is to find elevation of privileges vulnerabilities in undocumented, rarely used features present in the Windows operating system since more than fifteen or twenty years by now. As a side note, a similar (yet unrelated) issue in the same code area has been previously found by Tarjei Mandt back in 2010 and documented in his excellent “CVE-2010-3941: Windows VDM Task Initialization Vulnerability” post over two years ago. There is also more evidence of Windows VDM and its kernel-mode support (WOW32) being subject of in-depth security research in the past: for example, see “Microsoft Windows NT #GP Trap Handler Allows Users to Switch Kernel Stack” (Pwnie Award Winner) or “EEYE: Windows VDM Zero Page Race Condition Privilege Escalation“.

The vulnerability

Some basic information regarding internal structures used by the WOW-related win32k.sys system calls has already been described by Tarjei in his article. In short, GUI threads can call a “public” win32k!xxxRegisterUserHungAppHandlers routine (being a part of the win32k!apfnSimpleCall interface) either through the win32k!NtUserCallTwoParam system call or user32!RegisterUserHungAppHandlers – a convenient user-mode wrapper. The service is purposed to be used within the NTVDM.EXE process, a container for 16-bit DOS apps. It is primarily responsible for allocating a WOWPROCESSINFO kernel structure, assigning it to an internal ppiCurrent->pwpi field within PROCESSINFO (corresponding to the current process) and inserting into a linked list pointed to by a global win32k!gpwpiFirstWow symbol as shown on the following listing:

Read more

I hope you haven’t got bored with bypassing the Driver Signature Enforcement mechanism (present on all 64-bit Microsoft Windows operating systems since Vista) just yet – in either case, stay calm… this is going to be the last post of the series. After using multiple drivers shipped with the OS in the default configuration to trigger Blue Screens of Death from user-mode, and implementing a complete bypass of the functionality by using a design flaw in how the CSRSS subsystem interacts with the win32k.sys kernel module, I am going to present one final argument that the idea of preventing ring-3 applications with administrative privileges from causing bad things happen in kernel-mode is fundamentally flawed and would be never fully effective, unless a complete rewrite of the Windows kernel (including revisiting many low-level system assumptions) would be in order. Don’t keep it too seriously though – I am not claiming that the described Windows behavior has security implications of any kind – rather, it’s just a kernel curiosity illustrating how reliant the kernel is on certain assumptions that haven’t had a chance to be validated for many years.

To provide some context, several years ago Alex Ionescu and omega_red from the woodmann.com reverse-engineering forums discovered that invoking certain graphical system calls (i.e. the ones handled by win32k.sys) from within one of a few system processes would result in an unhandled kernel exception, a system bugcheck and potentially an exploitable condition (the original crash was caused by a NULL Pointer Dereference). None of the system processes would ever call the affected system services in a way that would bring the system down, so the only way for an attacker to achieve the same effect would be to inject a malicious payload into one of the highly-privileged processes and execute it – an activity which clearly takes an Administrator account to succeed.  Alex got so intrigued by the post that he performed an in-depth investigation of this weird behavior and later presented the results of his work along with some other win32k.sys security-related findings on the BlackHat US 2008 conference in a presentation called “Pointers and Handles: A Story of Unchecked Assumptions in the Windows Kernel“. In short, the graphical driver blindly dereferenced an internal pointer storing a reference to the caller’s desktop, but since some processes (e.g. CSRSS.EXE) were not assigned to any specific desktop, the kernel module would end up using a NULL pointer as a valid one: as straight-forward as it sounds.

Read more

First of all, it has been reported to me that the system call list for Microsoft Windows Vista SP0 available at j00ru.vexillium.org/syscalls/nt/32 was wrong, containing syscall numbers for beta2 version of the system instead of the actual RTM Service Pack 0. The issue has already been resolved – apologies for any confusion this might have caused.

Secondly, I have just recently had a presentation on ZeroNights 2012 in Moscow regarding reference counting and how its implementations found in the Windows kernel would often lead to exploitable local elevation of privileges conditions. The slides are available for over a week now – if you haven’t checked them out yet, be sure to take a look: “Windows Kernel Reference Count Vulnerabilities – Case Study“. The conference overall was really good – I enjoyed several interesting, (non-)technical talks by @thegrugq (“OPSEC: Because Jail is for wuftpd”), @NTarakanov (“The Art of Binary Diffing or how to find 0-dayz for free”), @d_olex (“Applied anti-forensics: rootkits, kernel vulnerabilities and then some”), @Agarri_FR (“That’s why I love XML hacking!”) and a few more. Additionally, the organizers really seemed to be trying their best to ensure painless and enjoyable trip and stay in Russia. One major drawback of the event is that even though it’s advertised to be an “international” conference, most of the talks were given in Russian (sometimes with live English translation), and so was the audience – I’m not quite sure how many foreign people (apart from the speakers) you could meet there – probably not too many :) Still, it’s a great idea to visit the conference and meet some of the leet Russian hackers that you wouldn’t have a chance to speak with, otherwise.

Last but not least, another issue of the great Hack In The Box Magazine was released just a few days ago – it’s now the ninth edition! To complete the tradition, I took care of the “Windows Security” section this time as well, preparing a brief article with a long title: “Memory Copy Functions in Local Windows Kernel Exploitation”. In short, some implementations of the standard memcpy and memmove functions tend to write data backwards (e.g. starting from the end of the destination memory region rather tham from the beginning) under certain circumstances, which appears to be an useful observation if the attacker has a certain degree of control over the dst, src and size parameters. I hope you will enjoy it.

The magazine can be downloaded from here (HITB-Ezine-Issue-009.pdf, 11.6 MB)

Read more