My next class:

Privilege escalation 0-day in almost all Windows versions

Published: 2010-11-24. Last Updated: 2010-11-24 21:56:08 UTC
by Bojan Zdrnja (Version: 2)
5 comment(s)

Today proof of concept code (source code, with a compiled binary) of a 0-day privilege escalation vulnerability in almost all Windows operating system versions (Windows XP, Vista, 7, Server 2008 ...) has been posted on a popular programming web site.

The vulnerability is a buffer overflow in kernel (win32k.sys) and, due to its nature allows an attacker to bypass User Access Control (UAC) on Windows Vista and 7 operating systems.
What’s interesting is that the vulnerability exist in a function that queries the registry so in order to exploit this the attacker has to be able to create a special (malicious) registry key. Author of the PoC managed to find such a key that can be created by a normal user on Windows Vista and 7 (so, a user that does not even have any administrative privileges).

The PoC code creates such a registry key and calls another library which tries to read the key and during that process it ends up calling the vulnerable code in win32k.sys.
Since this is a critical area of the operating system (the kernel allows no mistakes), the published PoC only works on certain kernel versions while on others it can cause a nice BSOD. That being said, the code can be probably relatively easily modified to work on other kernel versions.

We are not aware of any exploitation of this vulnerability at the moment and, since it can be exploited only locally, it obviously depends on another attack vector, but knowing how users can be easy on clicking on unknown files, this is definitely something we will keep our eye on and post updates if we see exploitation.

The PoC has been in the mean time removed from the original site but now that it has been published I’m sure that everyone who wants to get it can do that easily.

QUICK UPDATE:

I just wanted to confirm that the PoC works as advertised, as you can see below:

PoC

However, as expected (and stated by the PoC author), on my version of Windows 7, which has win32k.sys 6.1.7600.16667, it is unstable and causes a pretty nasty BSOD after couple of minutes (had even to restore the previous system state to get Windows to boot).

--
Bojan
INFIGO IS

 

5 comment(s)
My next class:

Comments

Interestingly, another privilege escalation vulnerability -in task scheduler- published last weekend (apparently used by the Stuxnet worm) didn't receive much media attention, see
http://www.h-online.com/security/news/item/Exploit-released-for-unpatched-Stuxnet-hole-1140196.html

Unbelievable that Microsoft's most "secure" operating systems (w7/w2k8) seem to use crc32 instead of a secure hash.
Yes, when searching for more details on the item mentioned in the article, I came across this which is the actual exploit mentioned by the above comment. I didn't analyze the exploit in detail, but it appears to me that MS must use a CRC-32 to "protect" the schedule... which is totally lame if that is the case.
http://www.exploit-db.com/exploits/15589/
A little bit more on http://www.prevx.com/blog/160/New-Windows-day-exploit-speaks-chinese.html and some more infos on http://nakedsecurity.sophos.com/2010/11/25/new-windows-zero-day-flaw-bypasses-uac/ - the later including kind of a workaround.
MS seems to be/may be aware of the issue acording to http://mobile.twitter.com/msftsecresponse/status/7590788200402945
Why not mention http://www.codeproject.com/KB/vista-security/uac.aspx as it has been taken down? Sure enough, there are detailed infos all around (e.g. http://softwareobjects.net/technology/other/bypassing-uac-with-user-privilege-under-windows-vista7/)
Are you sure this will work on Windows XP too? There's no HKCU\EUDC registry key...
@Ottmar, as can be read in http://pastebin.com/ReCGfJSf , the actual vulnerability is in the function RtlQueryRegistryValues - which, according to http://msdn.microsoft.com/en-us/library/ff562046%28v=vs.85%29.aspx , is available in Windows 2000 and later versions of Windows (although this doesn't mean all versions are vulnerable, this seems quite likely).

In the specific exploit, the publisher looked for a registry key that meets 2 criteria:

- it is writable by a non-privileged user;

- a kernel-mode OS function (GDI in this case) can be triggered to read a value from that specific registry key.

So the EUDC registry key is just one vector, others may exist.

Diary Archives