Announcement

Collapse
No announcement yet.

Win 7 HTML IFRAME tag exploit revealed

Collapse
This topic is closed.
X
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Win 7 HTML IFRAME tag exploit revealed

    http://www.theregister.co.uk/2011/12...ug_crash_risk/

    IF you are running Win7 while browsing the Internet and you see the BSOD shown in this video, you may be watching your Win7 box getting hacked.

    Here are the details:
    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/sour...erThemeWin.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:
    Code:
    #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.
    "A nation that is afraid to let its people judge the truth and falsehood in an open market is a nation that is afraid of its people.”
    – John F. Kennedy, February 26, 1962.

    #2
    Re: Win 7 HTML IFRAME tag exploit revealed

    I, hopefully, don't have to worry about that, since I have Firefox and IE9 both installed on my Windows 7 partition (/dev/sda1 = C. It appears that Firefox users aren't affected, at least not until the hackers include Gecko in their "compatibility" (for lack of a better term) list. Any word on whether it affects both 32- and/or 64-bit Windows users?
    The unjust distribution of goods persists, creating a situation of social sin that cries out to Heaven and limits the possibilities of a fuller life for so many of our brothers. -- Archbishop Jorge Mario Bergoglio of Buenos Aires (now Pope Francis)

    Comment


      #3
      Re: Win 7 HTML IFRAME tag exploit revealed

      Originally posted by bsniadajewski
      Any word on whether it affects both 32- and/or 64-bit Windows users?
      The default iexplore.exe process that runs on Windows x64 is the 32-bit version, so it doesn't really matter. Few people even know how to start the 64-bit .exe; it's pretty much unusable because few plugins will run in that one and even Office barfs on it.

      Comment

      Working...
      X