Crawling MSDN for fun and profit

Regardless of whether you are a Windows exploitation guru, a professional win32 application developer or someone whose curiosity occasionally tells him to dig up the MSDN library looking for interesting quirks or undocumented functionality, the following examples of MSDN article excerptions are very likely to look familiar to you:

Simply put, the operating system operates on an enormous number of structures, unions and flags defined and developed throughout the 20+ years of Windows being around. Many of them are used internally within userland, kernel space or both parts of a specific functionality implementation, while typical developers never get a chance to even learn about them. Often times, however, these constructs are used to actively communicate with the operating system from within third-party software, be it a regular word processor or a custom device driver for an uncommon sound card. While reading through the Microsoft documentation library (perhaps this also applies to other environments?), it is exceedingly easy to stumble upon a sentence like “don’t use it”, “always set it to zero” or “if you use it, Windows might format your C: disk you can encounter undefined behavior”. It always sounds very mysterious, but in reality, there can be only several different reasons for that:

Read moreCrawling MSDN for fun and profit

Defeating Windows Driver Signature Enforcement #2: CSRSS and thread desktops

To stand by my claim that the Microsoft Windows operating system has been built on the fundamental assumption that administrative privileges would always be equivalent to granting the ability to run arbitrary ring-0 code, I have decided to briefly discuss yet another portion of some Windows internals and how they could be easily misused by a system administrator to unlawfully cross the admin / kernel boundary on a X86-64 platform, and effectively elevate his rights on the machine by loading an unsigned device driver of his choice. The technique is directly related to CSRSS (the infamous Client/Server Runtime Subsystem), a part of Windows that has likely motivated most of the dirty relict hacks in the kernel that still remain visible in the most recent versions of the OS.

As usual, let’s start with some historical context. Back in July 2007, omega_red started a thread on the woodmann RCE forums, stating that he had found a GDI bug (Blue Screen of Death triggerable from user-mode) that required “pretty unusual conditions” to work. A few days into the discussion, Alex Ionescu chimed in and said that inspired by omega’s finding, he had spent a night looking around the win32k.sys module and located four vulnerabilities that he would be willing to present on the BlackHat conference; and so he did – the slides from his BlackHat USA 2008 conference talk titled “Pointer and Handles” can be found here. All issues discussed by Alex are fairly interesting, so be sure to check out the slides if you haven’t already; the important one for us would be the NULL Pointer Dereference within CSRSS.EXE via xxxCreateThreadInfo. The kernel routine would dereference an internal CurrentW32Thread->Desktop pointer without prior sanitization, thus using a pointer that was never initialized for the special subsystem process, in the first place. Oh, in fact there might be a “few more instances of such bugs in the kernel nowadays, but stay tuned… :-)

Read moreDefeating Windows Driver Signature Enforcement #2: CSRSS and thread desktops

Defeating Windows Driver Signature Enforcement #1: default drivers

One of the obvious things about the Windows operating system for anyone actively working on its kernel security is that the Driver Signature Enforcement (DSE in short) is not effective and can be bypassed with relative ease by any determined individual. From a historical perspective, the “feature” was introduced in the 64-bit build of Windows Vista in 2007 and has been shipped with all 64-bit Windows editions since then. In essence, it was designed to prevent unsigned device drivers (or kernel modules in general) from being loaded and executed with ring-0 privileges. Consequently, it broke one of the fundamental Windows assumptions followed since the early years of the NT family – administrative privileges in the system would no longer be equivalent to the ability to run arbitrary ring-0 code, effectively introducing a completely new layer of privilege separation in the system.

Soon after the change was presented to wide audience, the enforcement was spectacularly defeated by Joanna Rutkowska, who took advantage of the fact that users in the Administrators group had been granted access to raw disk data and thus were able to modify parts of the pagefile.sys swap file potentially containing paged-out ring-0 code, to later execute the injected payload by crafting a special kernel-mode request (IRP to the NULL.sys driver in that particular case). Joanna’s and Alexander’s presentation was titled IsGameOver() Anyone? and received quite a lot of media attention at the time (mid 2007), starting a global discussion regarding the sense and security implications of introducing the mechanism. As a direct outcome, Microsoft decided to address this particular attack by disabling user-mode access to raw disk contents, and later on follow up with additional page hash/signing implementation for the hibernation and swap files (thanks Alex!). Since five years ago, the mechanism hasn’t been publicly criticized or otherwise discussed anymore – perhaps everyone just got used to its existence and (in)effectiveness.

Read moreDefeating Windows Driver Signature Enforcement #1: default drivers