Defeating the Stack Based Buffer Overflow Prevention Mechanism of Microsoft Windows 2003 Server
David Litchfield · 2003
This paper presents several methods of bypassing the protection mechanism built into Microsoft’s Windows 2003 Server that attempts to prevent the exploitation of stack based buffer overflows. Recommendations about how to thwart these attacks are made where appropriate. Introduction Microsoft is committed to security. I've been playing with Microsoft products, as far as security is concerned, since 1997 and in the past year and a half or two I've seen a marked difference with some very positive moves made. In a way they had to. With the public relations crisis caused by worms such as Code Red Microsoft needed to do something to stem the flow of customers moving away from the Windows OS to other platforms. Microsoft's Trustworthy Computing push was born out of this and, in my opinion, I think we as consumers are beginning to see the results; or ironically not see them as the holes are just not appearing as they would if the security push wasn't there. We have, of course, seen at least one major security hole appear in Windows 2003 Server, this being the DCOM IRemoteActivation buffer overflow discovered by the Polish security research group, the Last Stages of Delirium [http://www.lsd-pl.net]. We will see more; but I am confident that the number of security vulnerabilities that will be discovered in Windows 2003 Server will be a fraction of those found in Windows 2000. Acknowledging that there have been holes found and that, yes, more will come to light in the future this paper is going to look at how, currently, the stack based protection built into Windows 2003 Server to protect against buffer overflow vulnerability exploitation can be bypassed. The development of this mechanism is one of the right moves made in the direction of security. An Overview of Windows 2003 Stack Protection Windows 2003 Server was designed to be secure out of the box. As part of the security in depth model adopted by Microsoft for their latest Windows version a new stack protection mechanism was incorporated into their compiler that was intended to help mitigate the risk posed by stack based buffer overflow vulnerabilities by attempting to prevent their exploitation. Technically similar to Crispin Cowan's StackGuard, the Microsoft mechanism places a security cookie (or canary) on the stack in front of the saved return address when a function is called. If a buffer local to that function is overflowed then, on the way to overwriting the saved return address, the cookie is also overwritten. Before the function returns the cookie is checked against an authoritative version of the cookie stored in the .data section of the module where the function resides. If the cookies do not match then it is assumed that the buffer has been overflowed and the process is stopped. This security mechanism is provided by Visual Studio .NET specifically the GS flag which is turned on by default. Currently the stack protection built into Windows 2003 can be defeated. I have engineered two similar methods that rely on structured exception handling that can be used generically to defeat stack protection. Other methods of defeating stack protection are available, but these are dependent upon the code of the vulnerable function and involve overwriting the parameters passed to the function. How is the cookie generated? When a module is loaded the cookie is generated as part of its start up routine. The cookie has a high degree of randomness which makes cookie prediction too difficult, especially if the attacker only gets one opportunity to launch the attack. This code represents the manner in which the cookie is generated. Essentially the cookie is the result of a bunch of XOR operations on the return values of a number of functions: #include #include