Message-ID: <20030714202800.852.qmail@www.securityfocus.com>
Date: 14 Jul 2003 20:28:00 -0000
From: Jason Sloderbeck <ops-lists@...itivenetworks.net>
To: bugtraq@...urityfocus.com
Subject: RE: IE chromeless window vulnerabilities




Here's a quick summary of the amazingly high risk to the vast majority of 
users running IE 5.5+ (including IE 6 SP1), even at the Medium security 
level. This may be redundant to some, but I'm not sure the full impact is 
obvious, especially since it's been around since 2001 and the advisories 
thus far have been marked as "Very low risk" and "Medium risk": 

- All browser-based SSL security is worthless

The attacker can direct you to an unencrypted site under his control and 
cover up his site's malicious address in the address bar 
with "https://www.etrade.com/" (or whatever) to make the user think 
he/she's really at your web site; someone malicious can even cover up the 
broken padlock with a gold padlock in the status bar, cover up the 
certificate warning, etc. And, even if you type in the URL yourself to be 
sure you're going to the right site, there's no way to know whether your 
address bar isn't actually a text box on a malicious form from some other 
page that's covering up your real address bar and redirecting you to the 
attacker's site.

- Any Windows application username & password can be intercepted

The user's desktop can be replaced with a full-screen fake desktop (Start 
button and all) that has a malicious password dialog in it that looks just 
like the real thing (or just the malicious dialog all on its own outside 
of the border of IE); think of the usernames and passwords a malicious 
person could get by displaying a Windows/Novell/Outlook/PeopleSoft/etc. 
password dialog in the middle of an employee's screen (you could even add 
a depressed button in their taskbar to look like the window was open, make 
the window draggable by the titlebar, etc.). When the victim enters their 
authentication credentials and clicks OK, their credentials are submitted 
via a form to a malicious web site. 

- ActiveX signing dialogs are worthless

They can be obscured to look like any application dialog in the world that 
you would click Yes on, and the No and Cancel buttons can be hidden. Or, 
someone malicious can just cover up "This control is unsafe/unsigned" 
with "This control has been signed by Microsoft, Inc.", complete with 
hyperlinkable text that works like the real thing.

Although the example given by Andrew is slow at the moment, this page 
should scare you (move the ActiveX dialog around after it has fully 
loaded):
http://www.doxdesk.com/personal/posts/bugtraq/20030713-ie/activex.html

All of this is possible because the user clicked on a link or opened a 
page -- they didn't have to click Yes on any JavaScript popup or ActiveX 
dialog, and these are just the obvious problems; I'm sure it only gets 
worse. 

*Clearly, there are exceptions to "All <blank> is worthless" and "Any 
<blank> can be intercepted", but the exceptions appear to be 
insignificant, given the scope of this vulnerability.

I just hope this helps the problem get fixed more quickly.

-Jason


--
Jason Sloderbeck
Positive Networks
jason@...itivenetworks.com
http://www.positivenetworks.com/


-----Original Message-----
From: Drew Copley [mailto:dcopley@...e.com] 
Sent: Monday, July 14, 2003 12:42 PM
To: 'Andrew Clover'; bugtraq@...urityfocus.com
Subject: RE: IE chromeless window vulnerabilities


This has been possible for sometime now. Guninski originally showed that 
this could be possible here:

http://www.guninski.com/popspoof.html

Date: 21 October 2001 

Image moving over download/open dialog: 
http://www.guninski.com/opf2.html 
BSOD emulation: 
http://www.guninski.com/bsod1.html 

All of these [above and below] works on IE 6, full patches, w2k3.

> -----Original Message-----
> From: Andrew Clover [mailto:and-bugtraq@...desk.com] 
> Sent: Sunday, July 13, 2003 12:20 PM
> To: bugtraq@...urityfocus.com
> Subject: IE chromeless window vulnerabilities
> 
> 
> Title: IE chromeless window vulnerabilities
> Affects: Internet Explorer 5.5 and later
> Risk: Medium
> 
> 
> Introduction
> ------------
> 
> A window without a frame, title bar, toolbars or scroll bars 
> is known as a 'chromeless' window. If a chromeless window can 
> be opened on top of other windows, it is possible to 
> impersonate Windows user interface elements.
> 
> Why is this a security problem? Because Windows and browser 
> UI elements are themselves part of security mechanisms. If 
> the UI for security features can be faked, users can be 
> tricked into making inappropriate decisions.
> 
> The 'traditional' way of doing chromeless windows was to use 
> the DHTML method window.open to open a full-screen browser 
> window (which is
> chromeless) and then resize this to smaller dimensions. This 
> capability was removed in IE6 Service Pack 1, presumably due 
> to exactly these security concerns.
> 
> 
> The problem
> -----------
> 
> It is still possible to get chromeless windows by using the 
> window.createPopup method. A window opened with createPopup 
> has some unusual properties:
> 
>   - It is closed when one clicks on the outside the popup. 
> This is easy
>     to circumvent by simply re-spawning it on close.
> 
>   - It cannot be focused. (It is impossible to put controls like text
>     input fields in it; this, at least, prevents us from overlaying
>     fake login forms onto other websites.) Focus stays with the opener
>     window.
> 
>   - It floats above other normal windows, allowing it to obscure them
>     even whilst they are focused.
> 
> One popup may be created per window, allowing one to overlay 
> an arbitrary rectangle of screen display area with fake UI. 
> More complicated overlays can be achieved by having multiple 
> windows opening popups at once; a popup is itself a window so 
> can be used to open further popups.
> 
> 
> Exploitation
> ------------
> 
> There are three simple exploit demonstrations at:
> 
  http://www.doxdesk.com/personal/posts/bugtraq/20030713-ie/

One fakes the address bar to seem to be another site; another tries to 
trick the user into adding a bookmark to the favorites menu
by hiding the dialog box that has focus; another hides an ActiveX download 
prompt in order to fool the user into allowing arbitrary
code to be run. These exploits are unpolished and could no doubt be made 
more convincing and robust, but this demonstrates the risk.


Solution
--------

window.createPopup() should have the same chromeless window restrictions as
createModalDialog() and createModelessDialog().


Workaround
----------

Disable Active Scripting.


Vendor response
---------------

Microsoft were informed of the problem on 23rd January. After initially 
encouraging e-mails, no action has been taken since.

I am posting this issue now as I have seen it being exploited in the wild.

If you use IE, be extremely wary of trusting what appear to be its built-
in security controls.

-- 
Andrew Clover
mailto:and@...desk.com
http://www.doxdesk.com/

Powered by blists - more mailing lists