bugtraq - Computer Terrorism Security Advisory (Reclassification) - Microsoft Internet Explorer JavaScript Window() Vulnerability

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date: 21 Nov 2005 12:34:29 -0000
From: securityadvisory@...puterterrorism.com
To: bugtraq@...urityfocus.com
Subject: Computer Terrorism Security Advisory (Reclassification) -
 Microsoft Internet Explorer JavaScript Window() Vulnerability

Computer Terrorism  (UK) 
========================

Security Advisory (Reclassification) :: CT21-11-2005
-----------------------------------------------------

Title:            Microsoft Internet Explorer JavaScript Window() Vulnerability

Author:           S. Pearson
Organisation:     Computer Terrorism (UK)
Web:              www.computerterrorism.com
Advisory Date:    21st November, 2005

Software:         Microsoft Internet Explorer 5.5 & 6.x
Severity:         Critical (Elevated from low) 
Impact:           Remote System Access
Solution Status:  ** UNPATCHED **
CVE reference:    CAN-2005-1790

Credits:          Benjamin Tobias Franz  (original bug)

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.

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

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

Examples:

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

Proof Of Concept:
-----------------

http://www.computerterrorism.com/research/ie/poc.htm

Temporary Solution:
-------------------

Until a patch is developed users are strongly advised to disable active scripting for 
non-trusted sites.

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.