Re: Internet Explorer and Opera local zone restriction bypass

From: Bipin Gautam hUNT3R (door_hunt3r_at_blackcodemail.com)
Date: 10/28/03

  • Next message: Thor Larholm: "Re: Mac OS X vulnerabilities"
    Date: 28 Oct 2003 20:05:22 -0000
    To: bugtraq@securityfocus.com
    
    
    ('binary' encoding is not supported, stored as-is) In-Reply-To: <20031025100233.6289.qmail@linuxmail.org>

    try this ...

    its dam strange to see WINXP LOGOFF WITHOUT ASKING MY PERMISSION

    file://c:\windows\system32\logoff.exe

    --------------------

    >Received: (qmail 3472 invoked from network); 27 Oct 2003 15:55:23 -0000
    >Received: from outgoing2.securityfocus.com (205.206.231.26)
    > by mail.securityfocus.com with SMTP; 27 Oct 2003 15:55:22 -0000
    >Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
    > by outgoing2.securityfocus.com (Postfix) with QMQP
    > id 492E98F57D; Mon, 27 Oct 2003 02:52:17 -0700 (MST)
    >Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
    >Precedence: bulk
    >List-Id: <bugtraq.list-id.securityfocus.com>
    >List-Post: <mailto:bugtraq@securityfocus.com>
    >List-Help: <mailto:bugtraq-help@securityfocus.com>
    >List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
    >List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
    >Delivered-To: mailing list bugtraq@securityfocus.com
    >Delivered-To: moderator for bugtraq@securityfocus.com
    >Received: (qmail 22041 invoked from network); 25 Oct 2003 03:57:25 -0000
    >Message-ID: <20031025100233.6289.qmail@linuxmail.org>
    >Content-Type: text/plain; charset="iso-8859-1"
    >Content-Disposition: inline
    >Content-Transfer-Encoding: 7bit
    >MIME-Version: 1.0
    >X-Mailer: MIME-tools 5.41 (Entity 5.404)
    >From: "Mindwarper *" <mindwarper@linuxmail.org>
    >To: "Thor Larholm" <thor@pivx.com>
    >Cc: bugtraq@securityfocus.com
    >Date: Sat, 25 Oct 2003 18:02:33 +0800
    >Subject: RE: Internet Explorer and Opera local zone restriction bypass
    >X-Originating-Ip: 213.8.132.107
    >X-Originating-Server: ws5-7.us4.outblaze.com
    >
    >I decided to use the flash cookie just as an example. I could have used for example the Macromedia Director cookie. Another way would be using IE temporary cookies because they allow html tags and most other ascii symbols except for ";" in the cookie name. So all I have to do is create a document.write script which writes the activex.
    >Another way would be using AIM's urlcache cookies which also apppear /Application Data/.
    >If Mozilla or Opera are installed it is also possible to use they're data which is stored in the /Application Data/.
    >The only problem is that I will still have to know the username of the victim.
    >
    >- Mindwarper
    >
    >----- Original Message -----
    >From: "Thor Larholm" <thor@pivx.com>
    >Date: Fri, 24 Oct 2003 21:54:32 -0700
    >To: "Mindwarper *" <mindwarper@linuxmail.org>,<bugtraq@securityfocus.com>
    >Subject: RE: Internet Explorer and Opera local zone restriction bypass
    >
    >> There was not a lot of details in your post, so I will try to verify and clarify your findings. First things first, this is not a problem with Microsofts Internet Explorer, but with Macromedia and their Flash player.
    >>
    >> I could reproduce this issue successfully with a fresh install of the latest Flash player, version 6.0.65.0, on fully patched versions of both IE6SP1 and Windows XP Pro.
    >>
    >> There are two completely new issues at hand here.
    >>
    >> The first issue is that Macromedia Flash allows you to store arbitrary content in a known location, that is %APPDATA%\Macromedia\Flash Player\YOURDOMAINNAME.TLD\YOURDOMAINNAME.sol. All flash cookies (which is what you set in your example, not browser cookies) from YOURDOMAINNAME.TLD are stored in this file.
    >>
    >> The issue is caused by Macromedias decision to store the contents of your Flash cookie in plaintext in this .SOL file. When IE later reads the file the "magic filetype" feature of Explorer reads the first 256 bytes, finds HTML content and determines to render the file as HTML since the target application is the browser, including your scripting.
    >>
    >> Being able to store arbitrary content in a known location is vital to any of the current range of IE exploits.
    >>
    >> Flash itself is a binary format, so this complete issue can easily be fixed by Macromedia by applying the same level of binary formatting to its Flash cookie contents, to provide slight obfuscation of the contents of Flash cookies when storing them on disk so Explorer does not misread its datatype.
    >>
    >> End-users can protect themselves against this exploit by changing how much data Flash applications are allowed to store on disk by going to http://www.macromedia.com/support/flashplayer/help/settings/global_storage.html and moving the slider all the way down, equivelant to checking the "Never Ask Again" checkbox on the page. When an updated version of the Flash player that fixes this is available, it is equally easy to change the setting back.
    >>
    >> System administrators can edit the file %APPDATA%\Macromedia\Flash Player\maromedia.com\support\sys\settings.sol and change the bytes at positions c7 and c8 to contain BF and F0, respectively (ASCII and ), to restrict data storage for Flash applications as an end-user would above. If you want to restore the file to default settings (for storing 100KB data) change the bytes back to 40 and 59, respectively (ASCII @ and Y).
    >>
    >> This is also why several people have said they could not reproduce the issue. They were either not logged in with the Administrator account, which your POC required, or they did not have the Macromedia Flash player installed.
    >>
    >> A similar issue was found way back with ID3 tags in Winamp and RealPlayer media files, and has been found on several occasions where a third-party non-Microsoft application allows you to store arbitrary content in a known location.
    >>
    >>
    >> The second issue is that IE lets you redirect to local files. This was restricted in IE6 SP1. While going over the source code in your POC, we discovered that it inadvertently redirects to a local file, despite the apparent restriction.
    >>
    >> When IE encounters a redirect such as the following
    >>
    >> Content-Location: file://c:/somefile.html
    >>
    >> it will disallow the action and not follow the redirect. However, your POC has one important alteration, which is the following
    >>
    >> Content-Location: file:///c:/somefile.html
    >>
    >> Did you notice that slight difference? Adding another slash to the URL circumvents the initial restriction, and when IE finally decides to load the URL in another part of its code it removes any excess slashes and properly loads file://c:/somefile.html
    >>
    >> The restriction imposed by IE6 SP1 is imposed on all local protocols, such as file:// and res://, and this new way to circumvent it equally applies to all local protocols. This means that you don't have to know the location of a specific file, but instead can open a ressource file available on all systems, such as
    >>
    >> Content-Location: res:///browselc.dll/mb404.htm
    >>
    >> Of course, since you could not inject any code in the ressource file you will now have to use another cross-domain scripting vulnerability in place of the Macromedia Flash vulnerability you identified in the first issue. On the positive side, it also means that you no longer have to guess the users Windows Logon name.
    >>
    >>
    >> In summary, when Macromedia changes their Flash player to no longer store Flash cookies in plaintext in a known location, this will no longer be an issue. All of the currently unpatched cross-domain scripting vulnerabilities are having patches produced, and since they have no easy POC exploits I doubt we will see any malicious use of the local file redirection variation you found.
    >>
    >>
    >>
    >> Regards
    >> Thor Larholm
    >> PivX Solutions, LLC - Senior Security Researcher
    >> http://pivx.com/larholm/ - Get our research, join our mailinglist
    >>
    >>
    >>
    >> -----Original Message-----
    >> From: Mindwarper * [mailto:mindwarper@linuxmail.org]
    >> Sent: Friday, October 24, 2003 6:53 AM
    >> To: bugtraq@securityfocus.com
    >> Subject: Internet Explorer and Opera local zone restriction bypass
    >>
    >> <snip http://www.securityfocus.com/archive/1/342317/2003-10-22/2003-10-28/0>
    >
    >
    >
    >-----------------------------|
    >- Mindwarper |
    >- mindwarper@linuxmail.org |
    >- http://mlsecurity.com |
    >-----------------------------|
    >
    >--
    >______________________________________________
    >Check out the latest SMS services @ http://www.linuxmail.org
    >This allows you to send and receive SMS through your mailbox.
    >
    >
    >Powered by Outblaze
    >


  • Next message: Thor Larholm: "Re: Mac OS X vulnerabilities"

    Relevant Pages

    • file redirection
      ... We would like to lock ... I configured the GP to redirect the desktop folder to ... Failed to perform redirection of desktop, Blah Blah, Access denied. ... I check the permission of the share and system has full control, ...
      (microsoft.public.windows.group_policy)
    • Re: file redirection
      ... could configure permissions to their local profile desktop folder to be only ... I configured the GP to redirect the desktop folder to ... > Failed to perform redirection of desktop, Blah Blah, Access denied. ... > I check the permission of the share and system has full control, ...
      (microsoft.public.windows.group_policy)
    • Re: Suppress email output of crontab job
      ... When I try to redirect the output to /dev/null I get a permission ... How can I suppress the emailing of this job? ...
      (comp.sys.mac.system)
    • Re: file redirection
      ... called settings) when you set the redirect policy? ... > to do this is to redirect the desktop and give the users ready only ... > Failed to perform redirection of desktop, Blah Blah, Access denied. ... > I check the permission of the share and system has full control, ...
      (microsoft.public.windows.group_policy)