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/WebCore/WebCore-658.28/rendering/RenderThemeWin.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.