[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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>