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.
Although you can think of it in terms of an additional barrier that ring-0 badware developers have to face, it certainly isn’t considered a security measure. Despite the extra separation level, admin → kernel escalations are not of much interest to the overall community, given that administrative rights are by far enough to compromise a system and guarantee infction persistence (with the small exception of the ability to communicate with machine peripherals, e.g. in order to set up a MBR/VBR rootkit). Additionally, a number of kernel-mode Windows components and features created in the pre-Vista era relies on ultimate trust to the Administrators group on so many levels that I really doubt it is realistically possible to reliably separate the two privilege levels at this point without investing an incredible amount of resources to introduce significant changes into the many areas of current system design.
I don’t usually pay too much attention to admin → kernel escalations when I sometimes stumble upon them during my daily work. However, today I would like to showcase an interesting set of bugs that I accidentally noticed a few weeks ago while doing some unrelated research. The nature of these bugs visibly exposes how flawed the signature enforcement idea has been from the very beginning. So, to the point: all device drivers present in the default Windows installation directory (Windows\system32\drivers) are obviously digitally signed and thus can be freely loaded or unloaded, assuming administrative privileges. Performing any of the two operations upon most .sys files doesn’t lead to any interesting behavior; however, if you attempt to unload some of them – or even better, load them in ring-0 more than once – you might end up triggering various types of Windows bugchecks, some of them in the most interesting locations or contexts I have seen in a long time. It turns out that these otherwise high-quality kernel modules fail to properly recover from encountering an error during DriverEntry initialization, or have serious bugs in the DriverUnload routines, most likely assuming that they would never be used anyway. Depending on the exact edition of Microsoft Windows, you can find up to 10 device drivers that are affected by the described flaws (out of ~300, if you’re interested in the metrics) in a default system installation.
Keep in mind that a system crash in one of those drivers doesn’t necessarily imply that it can be successfully exploited and used to run arbitrary ring-0 code. For instance, both DriverEntry and DriverUnload routines are typically called from within the System process, one that is inaccessible from user-mode; therefore, any NULL Pointer Dereferences occuring there aren’t of much use as they will always result in a Blue Screen of Death. As you will see, a few of the reproduced crashes are more complicated and affect the system state as a whole (e.g. by corrupting the kernel pools), therefore, they are likely enough to subvert the Driver Signature Enforcement mechanism. Ironically, a feature that was bypassed using a fairly complex attack and argued over for a long time could have been defeated with just the default drivers shipped with every Windows out there… that’s fascinating
Below are listed eight crashes that I have reproduced on a Windows 7 SP1 64-bit machine; additionally, there is one more case of a driver that only fails under the new Windows 8 operating system. For each discussed driver, you can also find a short explanation of the programming bug that led to the bugcheck. I’m intentionally not including reliable exploits for any of the issues. Some of them do seem like good exploitation candidates, though Have fun!