This document details a denial of service vulnerability I've recently discovered in current versions of Microsoft Windows. If, from user mode, you a make very specific set of operating system calls you can cause your entire Windows Operating System to blue screen. The complete code (in C) used to trigger the bug as well as a makefile can be found at the end of the document, USE AT YOUR OWN RISK, the author is not liable for any damage you manage to inflict upon your machine while running it. This bug affects fully updated versions of Windows 7 as of 10/16/2012, Windows Vista is probably also vulnerable. I lack the expertise and resources to determine whether the bug allows for arbitrary code execution, but I have confirmed that it can at least be used to corrupt kernel memory and cause a denial of service. I stumbled accross the bug inadvertently while working on something totally unrelated to security, and decided to publish my findings so that this can be fixed by Microsoft. This article aims to explain my technical findings and sum up the impact of the discovery, and it assumes advanced programming and systems architecture knowledge on the part of the reader. Let's get down to the details. Here is the most important part of the code that triggers the crash.
Looking at the stack trace, there appears to be some kind of race condition involving some local procedure calls. I've run this experiment many times and the client server runtime system inevitably faults, though not always with an access violation. In this particular stack trace, the bottommost frame is 0x772c15da, an address somewhere in usermode close to where ntdll was sitting when the fault occurred. To re-iterate, I can't say whether or not this bug could be engineered to bring about execution of arbitrary code. That determination needs to be made by a Windows system programmer. Hopefully somebody at Microsoft will conduct a deeper analysis and fix this problem. A tarball of the complete code and makefile (two text files, less than two kilobytes compressed) is available here. The author, Max, can be reached by e-mail here: max[4t]megafrock[d@t]com.