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” ?
Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
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:
Here is the raw dump:
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.