Windows Kernel-mode GS Cookies and 1 bit of entropy

I would like to present the results of a research performed by Gynvael Coldwind and me during the last three or four weeks – an almost 40-page long article, entitled “Exploiting the otherwise non-exploitable: Windows Kernel-mode GS cookies subverted” (yes, that’s an obvious reference to the “Exploiting the otherwise non-exploitable on Windows” by Skywing and Skape, Uninformed 4). The paper aims to describe the current protection level of a specific stack protection found in a majority of Windows device drivers (both default and 3rd party) – the GS cookies, and cover the cookie generation weaknesses, found in the actual protection implementations on Windows XP, Windows Vista and Windows 7 (both 32-bit and 64-bit platforms).

As it turns out, all of the entropy sources used to form the final cookie value – preventing the attacker from hijacking the return address – are extremely weak, and therefore easy to guess or calculate by a potential attacker. A total of five cookie-prediction techniques can be found in the article; three of which are designed to estimate the system tick count (the only truly unknown factor of the cookie value), with the highest possible accuracy degree. Apart from theoretical considerations, we have also performed a number of practical tests, proving the real effectiveness of the presented methods. By making use of the most precise measurement techniques we are currently aware of, we have managed to reach around 50% of cookie prediction reliability (and thus, the same degree of stack-based vuln exploitability).

Inspired by a related article (“Reducing the effective entropy of GS cookies” by skape, Uninformed 7) I would like to present three example charts, summing up the general results achieved by the authors, in the field of cookie entropy reduction. The experiments were performed on a regular computer (not a virtual machine) with the Microsoft Windows XP SP3 operating system installed, and are based on the cookie value of the standard win32k.sys kernel module.

Legend: A value of 1.0 means that the given bit can be predicted with 100% accuracy (i.e. no entropy). A value of 0.5 means that the given bit can be predicted with 50% accuracy – the 0/1 bit decomposition is equal, providing a maximum entropy level.

What this actually means, is that a certain group of the stack-based buffer overflow vulnerabilities found within Windows kernel modules are no longer considered Denial of Service class; instead, they are possible Elevation of Privileges vulns, that can be exploited with a varying success rate (depending on numerous factors). One example of such vulnerability is CVE-2010-4398; the security flaw has been disclosed as a 0-day on 26th November 2010, by a Chinese hacker called noobpwnftw. Originally, the discoverer shared a brief summary of the vulnerability (concept, reason, versions affected), a Proof of Concept source code, and a video recording, confirming successful exploitation on the Windows Vista platform.

A little confusion amongst the community (at least on the Polish side of the net) was caused by the fact that the advisory author explicitly noted that the example exploit is capable of bypassing UAC, and the exploit itself was only compatible with the two latest Microsoft operating systems. Upon reading a couple of comments stating that Windows XP is not affected by the vulnerability, me and Gynvael decided to investigate the issue more, and figure out what’s going on, by ourselves. Interestingly, not only did we confirm that Windows XP was prone to the security flaw, but we also found out that the win32k.sys version is GS-protected, as opposed to Windows Vista and 7. Therefore, one of the main reasons for taking up the research was to make the issue exploitable on Windows XP.

Fortunately, thanks to the developed cookie prediction techniques, we did manage to create an almost reliable (with the success rate of around 46%, as presented in the paper) Proof of Concept program. A successful elevation of privileges, achieved by estimating the GS cookie and exploiting the CVE-2010-4398 vulnerability is presented on the following video:

Download

The full article can be downloaded from the following location: link (PDF, 885kB).

Vendor timeline

6 December 2010: Initial e-mail to Microsoft informing that our research indicates that the ring-0 driver cookies are predictable.

6 December 2010: Initial vendor response, confirming reception.

8 December 2010: Second vendor response. Vendor was aware of the low entropy of the cookies and agrees that our approach is reasonable. Vendor states that there are no plans in updating the mechanism in the current version of the system, and that the issue is planned to be addressed in the next release of Windows. Vendor did not request the paper to be released later than the authors originally planned.

4 January 2011: Final “ping” to vendor. Some e-mails were exchanged, but delay in publishing was not requested.

11 January 2011: The paper is published.

Thanks

We would like to thank the following people for reviewing, commenting, and suggesting numerous improvements to the paper: Unavowed, Tavis Ormandy, Marc-Antoine Ruel, Carlos Pizano, Matt Miller and deus.

Conclusion

The general purpose of the paper is to show, how an ultimate protection scheme implemented in the Windows drivers is prone to certain weaknesses, which can further used to perform successful stack-based vulnerability exploitation, provided local access to the target machine. Due to the current state of things, some of the already-known security flaws, considered Denial of Service class up to this moment, now become a “Possible elevation of privileges”, thanks to the GS cookie prediction techniques. The outlined issues are also going to work in the context of possibly upcoming, and not yet known vulnerabilities, since the GS cookie mechanism is not claimed to be improved in the near future. One should keep in mind, however, that the invented techniques can be only applied to a certain group of devices; what’s most important, they do not work for the Windows core kernel image – ntoskrnl.exe.