('binary' encoding is not supported, stored as-is) 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 jasonat_private http://www.positivenetworks.com/ -----Original Message----- From: Drew Copley [mailto:dcopleyat_private] Sent: Monday, July 14, 2003 12:42 PM To: 'Andrew Clover'; bugtraqat_private 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-bugtraqat_private] > Sent: Sunday, July 13, 2003 12:20 PM > To: bugtraqat_private > 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:andat_private http://www.doxdesk.com/
This archive was generated by hypermail 2b30 : Mon Jul 14 2003 - 13:42:37 PDT