[security-alerts] Fwd: [Full-disclosure] Computer Terrorism Security Advisory (Reclassification) - Microsoft Internet Explorer JavaScript Window() Vulnerability
Да, все плохо, код можно выполнить вообще любой, не обязательно просто
вызвать внешнее приложение.
--This is a forwarded message
From: securityadvisory <securityadvisory@xxxxxxxxxxxxxxxxxxxxx>
To: full-disclosure@xxxxxxxxxxxxxxxxx <full-disclosure@xxxxxxxxxxxxxxxxx>
Date: Monday, November 21, 2005, 4:40:48 PM
Subject: [Full-disclosure] Computer Terrorism Security Advisory
(Reclassification) - Microsoft Internet Explorer JavaScript Window()
Vulnerability
===8<==============Original message text===============
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:
-----------------
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.
_______________________________________________
Full-Disclosure - We believe in it.
Charter:
Hosted and sponsored by Secunia -
===8<===========End of original message text===========
--
~/ZARAZA
ЭНИАКам - по морде! (Лем)
