When I started this project, I had one goal in mind – to understandwhich binaries in Windows Vista were not /GS compiled. While this mayseem rather simple on the surface, as I started to dig, it became alittle more complex. That said, my goal was achievable and today I’mhappy to present my findings.
The purpose of my paper "Analysis of GS Protection in Windows Vista"was to show which binaries under a default installation of WindowsVista 32bit RTM were not protected by the Visual Studio 2005 /GScompiler flag. This, in turn, was designed to help Symantec and ourclients understand any exposure, either direct or indirect, which mayresult from this lack of protection.
The abstract for my paper is as follows:
Visual Studio 2002 introduced the Buffer Security Check(GS) option to protect stack variables from overflows that resulted inarbitrary code execution. We developed techniques to identify thepresence of GS protection in binaries and used them to identify whichprograms are and which programs are not protected by the GS option inthe 32-bit RTM release of Windows Vista.
What do the results tell us? Well, most of Windows Vista 32bit RTMis actually /GS compiled. However, there were ~150 binaries under theC:\Windows directory that do not contain GS protected code. What wasmost apparent, and worrying to me, was the exposure provided bythird-party kernel drivers – please note this is not Microsoft authoredcode. That is, there is code that exists at the center of the TrustedComputing Base that is not /GS compiled. These drivers do not implementthe most basic protection mechanisms available against a very wellunderstood and historically common class of vulnerability. The examplesobserved during the course of this research were virtual hardwaredrivers. With aggressive moves to virtualized environments in theenterprise, there is an ever increasing likelihood that these would bepresent on a number of hosts. In addition to the virtual hardwaredrivers, I also observed other examples of drivers not being GScompiled such as CD emulators (i.e., ISO mounters).
Why does this matter? Well, it only takes one driver for a commonpiece of hardware, either real or virtualized, to have a vulnerabilitythat is exploitable from userland to pose a significant problem("userland" is where user application execute in OS’s as opposed tokernel). This vulnerability could in turn undermine the improvementsseen in Windows Vista such as PatchGuard. An attacker would then have away to inject code into the kernel and, thus, patch the relevant partto disable PatchGuard, Code Integrity, and the like. This is aplausible and very worrying scenario. These 3rd party kernel driverproviders need to ensure they get their houses in order.
Aside from the direct Vista research, I think this paper will be ofuse to anyone who wants to understand how /GS works and how well itdoes it. Additionally, I think it might be useful to other securityresearchers and penetration testers who want to understand which codethey should discount when looking for stack overflows. That’s it fromme, unless you're coming to see my presentations on this or my ASLRresearch, which I will be giving at BlackHat DC, EuSecWest, andBlackHat Europe.