Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Exploits-HackingTools
[Top] [All Lists]

[NT] Microsoft Internet Explorer JavaScript Window() Code Execution

Subject: [NT] Microsoft Internet Explorer JavaScript Window() Code Execution
Date: 29 Nov 2005 11:41:55 +0200
The following security advisory is sent to the securiteam mailing list, and can 
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html 

- - - - - - - - -



  Microsoft Internet Explorer JavaScript Window() Code Execution
------------------------------------------------------------------------


SUMMARY

By crafting special Javascript string, attackers can cause Internet 
Explorer to execute arbitrary code.

DETAILS

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.

Proof of Concept:
 <http://www.computerterrorism.com/research/ie/poc.htm> 
http://www.computerterrorism.com/research/ie/poc.htm


ADDITIONAL INFORMATION

The information has been provided by  
<mailto:securityadvisory@computerterrorism.com> computerterrorism.com.
The original article can be found at:  
<http://www.computerterrorism.com/research/ie/ct21-11-2005> 
http://www.computerterrorism.com/research/ie/ct21-11-2005



======================================== 


This bulletin is sent to members of the SecuriTeam mailing list. 
To unsubscribe from the list, send mail with an empty subject line and body to: 
list-unsubscribe@securiteam.com 
In order to subscribe to the mailing list, simply forward this email to: 
list-subscribe@securiteam.com 


==================== 
==================== 

DISCLAIMER: 
The information in this bulletin is provided "AS IS" without warranty of any 
kind. 
In no event shall we be liable for any damages whatsoever including direct, 
indirect, incidental, consequential, loss of business profits or special 
damages. 




<Prev in Thread] Current Thread [Next in Thread>
  • [NT] Microsoft Internet Explorer JavaScript Window() Code Execution, SecuriTeam <=