RE: Internet Explorer and Opera local zone restriction bypass
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@xxxxxxxx>
Date: Fri, 24 Oct 2003 21:54:32 -0700
To: "Mindwarper *" <mindwarper@xxxxxxxxxxxxx>,<bugtraq@xxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxx]
> Sent: Friday, October 24, 2003 6:53 AM
> To: bugtraq@xxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxx |
- 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