14.4 Defeating Buffer Overflow Prevention

In September 2003, David Litchfield discovered a method to exploit the buffer overflow prevention system in Windows 2003 Server, which we include here with his permission. The problem lies in the Windows stack protection mechanism. Microsoft incorporated this protection mechanism into Windows 2003 Server to help mitigate the risk posed by stack-based buffer overflow vulnerabilities. Like StackGuard (discussed in Chapter 5), 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, the cookie is overwritten on the way to overwriting the saved return address. 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 the system terminates the process because it assumes that a buffer overflow has occurred.

According to Litchfield, when a module is loaded the cookie is generated as part of its startup 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 <stdio.h> #include <windows.h> int main(  ) { FILETIME ft; unsigned int Cookie=0; unsigned int tmp=0; unsigned int *ptr=0; LARGE_INTEGER perfcount; GetSystemTimeAsFileTime(&ft); Cookie = ft.dwHighDateTime ^ ft.dwLowDateTime; Cookie = Cookie ^ GetCurrentProcessId(  ); Cookie = Cookie ^ GetCurrentThreadId(  ); Cookie = Cookie ^ GetTickCount(  ); QueryPerformanceCounter(&perfcount); ptr = (unsigned int)&perfcount; tmp = *(ptr+1) ^ *ptr; Cookie = Cookie ^ tmp; printf("Cookie: %.8X\n",Cookie); return 0; } 

The cookie is an unsigned int, and once it has been generated it is stored in the .data section of the module. However, the .data section's memory is writable, leaving it vulnerable to attack by overwriting this authoritative cookie with a known value and overwriting the stack cookie with the same value. As a countermeasure, Litchfield recommends that Microsoft mark the 32 bits of memory where this cookie is stored as read-only in order to prevent the attack.