RE: Internet Explorer and Opera local zone restriction bypass

["Mindwarper *" <mindwarper@linuxmail.org>]

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