Who framed Internet Explorer (GM#010-IE)

From: GreyMagic Software (securityat_private)
Date: Mon Sep 09 2002 - 08:31:07 PDT

  • Next message: Dave Aitel: "Unmask 1.0 Release Party at My House!"

    GreyMagic Security Advisory GM#010-IE
    =====================================
    
    By GreyMagic Software, Israel.
    09 Sep 2002.
    
    Available in HTML format at http://security.greymagic.com/adv/gm010-ie/.
    
    Topic: Who framed Internet Explorer.
    
    Discovery date: 04 Aug 2002.
    
    Affected applications:
    ======================
    
    Microsoft Internet Explorer 5.5 and above; prior versions are not
    vulnerable.
    
    Note that any other application that uses Internet Explorer's engine
    (WebBrowser control) is affected as well (Outlook, MSN Explorer, etc.).
    
    
    Introduction:
    =============
    
    The <frame> and especially <iframe> (inline frame) elements are popular
    elements on many big web sites. <frame> elements have always been used and
    <iframe> elements recently became popular in ads and relative content, since
    they don't suffer from the same clumsiness regular <frame> elements suffer
    from.
    
    Most big sites will contain a <frame> or an <iframe> element somewhere
    inside them. Good examples are hotmail.com, google.com and microsoft.com.
    
    Frames may contain URLs in other domains or protocols, and therefore have
    strict security rules, which prevent frames in one domain to access content
    and information in another. Microsoft explains the issue in this Cross-Frame
    Scripting article -
    http://msdn.microsoft.com/workshop/author/om/xframe_scripting_security.asp.
    
    
    Discussion:
    ===========
    
    We discovered that it is possible for an attacker to execute script on any
    page that contains <frame> or <iframe> elements, ignoring any protocol or
    domain restriction set forth by Internet Explorer. This means that an
    attacker can steal cookies from almost any site, access and change content
    in sites and in most cases also read local files and execute arbitrary
    programs on the client's machine (script in the "My Computer" zone).
    
    After a web site gets loaded, it is still possible for an external domain to
    access its frames collection. That in itself is not helping the attacker,
    since the document object of these frames cannot be accessed directly.
    
    However, it is possible to set the frame's URL. Setting the child frame's
    URL to "javascript:[code]" will execute the script in the context of the
    currently loaded URL.
    
    This vulnerability will not work, however, if the child frame is in a
    different domain than the victim's, like most ads are. But even that doesn't
    stop this vulnerability from being exploited, an attacker can simply change
    the frame's URL to match its parent and then re-assign the
    "javascript:[code]" URL.
    
    In order to use this vulnerability to access the "My Computer" zone an
    attacker would have to find a local file or resource that contains a <frame>
    or an <iframe>. Fortunately for the attacker, Microsoft provided such a
    resource in Internet Explorer 6, and to make it even better, Microsoft also
    ironically named it "PrivacyPolicy.dlg". All an attacker needs to do in
    order to read local files and execute arbitrary programs is to load
    "res://shdoclc.dll/privacypolicy.dlg" and then change the URL of the frame
    it contains to the "javascript:[code]" URL.
    
    Luckily for Internet Explorer 5.5 users, "PrivacyPolicy.dlg" was only
    supplied in version 6 of the browser. However, Windows ships with several
    HTML files, in relatively static locations, that may contain frames. An
    attacker can run a simple scan on such known local files and when such a
    file is found the attacker can use it like "PrivacyPolicy.dlg" is used above
    
    
    Exploit:
    ========
    
    This exploit shows how it is possible to read a user's cookie in google.com,
    it uses a new window to load the victim site, the child frame is Google's
    messages tree frame.
    
    <script language="jscript">
    onload=function () {
        var
    oVictim=open("http://groups.google.com/groups?threadm=anews.Aunc.850","OurVi
    ctim","width=100,height=100");
        setTimeout(
            function () {
                oVictim.frames[0].location.href="javascript:alert(document.cooki
    e)";
            },
            7000
        );
    }
    </script>
    
    
    Solution:
    =========
    
    Disable Active Scripting.
    
    
    Tested on:
    ==========
    
    IE5.5 Win98.
    IE5.5 NT4.
    IE6 Win2000.
    IE6 WinXP.
    
    
    Demonstration:
    ==============
    
    We put together four proof-of-concept demonstrations:
    
    * Simple: The example shown in the "Exploit" section.
    
    * "Who framed" Console: Automatically test any site for frames and execute
    commands on it.
    
    * Privacy, anyone? #1: Read local files using the privacypolicy resource or,
    if you own a prior version of IE, scan your disk for "standard" local files
    that contain frames in order to "bounce" to any local file from them.
    
    * Privacy, anyone? #2: Execute arbitrary programs using the privacypolicy
    resource or, if you own a prior version of IE, scan your disk for "standard"
    local files that contain frames in order to "bounce" to program execution
    from them.
    
    They can all be found at http://security.greymagic.com/adv/gm010-ie/.
    
    
    Feedback:
    =========
    
    Please mail any questions or comments to securityat_private
    
    - Copyright © 2002 GreyMagic Software.
    



    This archive was generated by hypermail 2b30 : Mon Sep 09 2002 - 10:40:23 PDT