Vulnerable Systems:
* Microsoft Internet Explorer version 5.5
* Microsoft Internet Explorer version 6
The JavaScript "Window()" function when used in conjunction with a <BODY onload> event. As a result, Internet Explorer encounters an exception when trying to call a dereferenced 32bit address located in ECX, as highlighted by the following line of code:
CALL DWORD [ECX+8]
Due to the bug, ECX is inadvertently populated by the Unicode representation of a text string named "OBJECT", or more specifically 0x006F005B. As offset 0x006F005B points to an invalid (or non-existent) memory location, Internet Explorer fails to progress, and in turn the end user experiences an application crash (DoS).
Therefore, as the bug does not yield control of any internal register and/or points to an offset of which we have no control, the original "low" risk classification clearly reflects the improbable scenario for remote code execution.
If we take a closer look at the vulnerability, we actually see that the instruction is trying to dereference an offset in the range of 0x00600000, which, coincidently, is reserved for the facilitation of all opened Window characteristics on the desktop.
These structures vary in both length and content, but in the main, take the form of window titles, buttons, and any File/edit/View menus bars attributable to a particular Window session.
Consequently, it is feasible to assume that offset 0x006F005B could be arrived at through the invocation of several new Windows structures, for example circa 12 new web browsing sessions, which would increment 0x00600000 into 0x006F005B.
If this were possible, it would just leave the problem of trying to identify a means by which custom shellcode could be inserted via one of the Window Elements, and correctly aligned against the called [0x006F005B].
Accordingly, several methods were tested. By using a combination of multiple open windows (expanding the memory section), and legal techniques that allow the modification of certain Window elements (examples below), 3rd party code execution was eventually realised!
Example:
1. Long HTML <TITLE>
2. Long embedded Document File Names
3. Large Alert Boxes
Unfortunately, all methods tested suffered from one major flaw - inconsistency.
The assumption that a potential victim has a clean desktop (no open applications) compounded by the fact that most window elements encompasses some form of content length restriction, results in a very small opportunity for any realistic exploitation.
Except, for one particular approach... a JavaScript prompt box.
By employing a simple technique to invoke multiple occurrences of large JavaScript prompt Boxes, it is possible to flood/saturate the remoteness between 0x00600000 - 0x006F005B ++ with data of our choice, yielding very reliable execution of arbitrary code.
