A forum for reverse engineering, OS internals and malware analysis 

Discussion on reverse-engineering and debugging.
 #10565  by Evilcry
 Sat Dec 24, 2011 7:02 am
Description of the Win7 "Remote" Win32k.sys/Webkit Exploit
The bug happens due to a NineGrid request coming through GdiDrawStream sent on behalf of the UX Theme DLL which handles Windows Themes starting in XP and later.

Webkit browsers (along with IE8 -- but not IE9, it would seem) attempt to render HTML elements on the page using the native skin of the OS. In this case, in the drawControl function (see http://www.opensource.apple.com/source/ ... emeWin.cpp), DrawThemeBackground is called, which handles skinning of OS controls.

A 96 (0x60) byte buffer is sent (parameter 2 and 3 of GdiDrawStream are the size and buffer address, parameter 1 is the HDC).

Draw Steam buffers begin with a magic value, followed by a series of commands identified by a 32-byte market. Here is the stream sent with the special iframe when viewed in Safari:

44727753 = 'DrwS' = DrawStream Magic

Command Buffers:

#0: 00000000 <SET TARGET>
3b01017a // Destination DC (hdc) *** Must match HDC in GdiDrawStream argument 1 ***
// Destination Clip (ERECTL):
0000011b // Left
00000011 // Top
0000012c // Right
0089f580 // Bottom *** Multiply by 2, and you get the "magic" value used in the iframe PoC ***
#1: 00000001 <SET SOURCE>
058506a3 // Source Surface (pso) *** Dumped the surface from kernel mode, got a 13x5 32BPP bitmap which is the Luna/Aero scrollbar slider control ***
#2: 00000009 <NINEGRID>
// Destination Clip (ERECTL): *** Should match the Destination Clip of the Target
0000011b // Left
00000011 // Top
0000012c // Right
0089f580 // Bottom
// Source Clip (ERECTL): *** Should be within the bounds of the surface (which is 13x5 in this case)
00000000 // Left
00000000 // Top
0000000e // Right
00000001 // Bottom
// NINEGRID_BITMAP_INFO *** Documented in RDP docs. Should fit within the surface and destination.
00000001 // Flags (DSDNG_STRETCH)
0000000a // Left Width
00000003 // Right Width
00000000 // Top Height
00000000 // Bottom Height
00000000 // Transparent

Here is the raw dump:

0: kd> dds @r8 l18
00000000`003be664 44727753
00000000`003be668 00000000
00000000`003be66c 2b0108d5 // HDC, this will change from dump to dump
00000000`003be670 0000011b
00000000`003be674 00000011
00000000`003be678 0000012c
00000000`003be67c 0089f580
00000000`003be680 00000001
00000000`003be684 018503c2 // Bitmap Surface, this will change from dump to dump
00000000`003be688 00000009
00000000`003be68c 0000011b
00000000`003be690 00000011
00000000`003be694 0000012c
00000000`003be698 0089f580
00000000`003be69c 00000000
00000000`003be6a0 00000000
00000000`003be6a4 0000000e
00000000`003be6a8 00000001
00000000`003be6ac 00000001
00000000`003be6b0 0000000a
00000000`003be6b4 00000003
00000000`003be6b8 00000000
00000000`003be6bc 00000000
00000000`003be6c0 00000000

What are you essentially seeing is an iframe that has a particularly interesting height, that when the scrollbar is being drawn and themed, a math error in the NineGrid transform causes an out-of-bounds write. This PoC would work in IE 8, but IE 8 has a well known CSS bug where it has a maximum pixel limit (around 1342177), which is why it doesn't immediately manifest itself.

*OTHER HEIGHTS ARE EXPLOITABLE*, and some may be small enough such that even IE 8 hits the NineGrid height corner case.

IE9 does not seem to theme controls using UxTheme at all, and its scrollbar behavior is different from IE 8, so even though the pixel limit is no longer there, the PoC did not work. Firefox was not tested.

*NOT ONLY IFRAMES ARE VULNERABLE*. Testing with an HTML <button> of the same height resulted in a crash in Safari as well.

What this means is that *any* client, local or remote, that does skinning of the controls (i.e.: almost all of them -- even a button on a flash PDF) could result in a NineGrid transform that hits this bug. It's not at all specific to WebKit.
Above text comes from a pastebin, author is unknown.