|
Security Advisory (Reclassification) : CT21-11-2005
Internet Explorer JavaScript Window() Remote Code Execution
| Affected Software: |
Microsoft Internet Explorer 5.5 & 6.x |
| Severity: |
Critical
(Elevated from
low) |
| Impact: |
Remote System
Access |
| Solution Status: |
Patch now available (see below) |
| CVE
Reference:
|
CAN-2005-1790 |
|
Advisory Date: |
21st November,
2005 |
| |
|
| Credits:
|
Benjamin Tobias
Franz (original bug) |
1. OVERVIEW
This document serves as a
reclassification advisory for the Microsoft Internet Explorer JavaScript
Window() DoS vulnerability, originally reported on 31/05/2005.
Contrary to popular beliefs, the aforementioned security issue is susceptible
to remote, arbitrary code execution, yielding full system access with the
privileges of the underlying user.
2. TECHNICAL NARRATIVE
As well documented, the
vulnerability is instigated by IE's failure to correctly initialise 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 (Denial of Service).
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.
How improbable?
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 large 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 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 Window elements (examples below), 3rd party code
execution was eventually realised!
Examples:
1. Long HTML <TITLE>
2. Long 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 apps) compounded by the fact that most window elements encompasses some
form of content length restriction, result in 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.
3. PROOF OF CONCEPT
http://www.computerterrorism.com/research/ie/poc.htm
4. TEMPORARY SOLUTION
Until a patch is
developed, users are advised to disable active scripting for non-trusted
sites.
5. VENDOR STATUS
The original DoS
vulnerability was brought to the public's attention on the 31/05/2005 by
Benjamin Tobias Franz. To date, the vendor has failed to publicly
acknowledge the presence of the flaw, or provide any timescales for an
appropriate fix. Accordingly, as of the date of this document, this
vulnerability remains UNPATCHED, affecting all users of Microsoft Internet
Explorer version 5.5 and 6.x respectively.
13th December 2005 -
Microsoft release patches
Internet Explorer 5.01 SP 4 on Microsoft Windows 2000
(requires SP 4)
Internet Explorer 6 SP 1 on Microsoft Windows 2000
(requires SP 4) or on Microsoft Windows XP (requires SP 1)
Internet Explorer 6 for Microsoft Windows XP (requires
SP 2)
Computer Terrorism (UK)
Home |
Contact Us |
Services |
News |
|
|
