[NT] Internet Explorer and Opera Local Zone Restriction Bypass (Exploit)
From: SecuriTeam (support_at_securiteam.com)
Date: 10/28/03
- Previous message: SecuriTeam: "[TOOL] Btscanner - Bluetooth Scanner"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: list@securiteam.com Date: 28 Oct 2003 12:02:21 +0200
The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Internet Explorer and Opera Local Zone Restriction Bypass (Exploit)
------------------------------------------------------------------------
SUMMARY
Microsoft Internet Explorer does not allow local file access by a remote
host by default. By creating an iframe that points on a specially crafted
CGI script (using the location header to confuse IE), it is possible to
cause IE to execute any local file through the iframe with local zone
restrictions. This then allows remote arbitrary file execution on the
victim without having the victim do a thing besides loading the page.
Opera seems to not only be affected by this vulnerability, but it also
allows direct local file access through iframes without any CGI scripts.
Unlike IE where it is possible, to set ActiveX objects to execute
arbitrary files, in Opera it is not.
DETAILS
Vulnerable systems:
* Internet Explorer 6.0 SP1 and 6.0
* Flash player version 6.0.65.0
Technical details:
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 mis-read its
datatype.
A similar issue was found 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, Thor
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
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 do not have to know the
location of a specific file, but instead can open a resource 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 resource 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 un-patched cross-domain scripting
vulnerabilities are having patches produced, and since they have no easy
POC exploits Thor doubts we will see any malicious use of the local file
redirection variation Mind Warper found.
Workaround:
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> http://www.macromedia.com/support/flashplayer/help/settings/global_storage.html and moving the slider all the way down, equivalent 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).
Exploit:
Mind Warper has created a proof of concept page:
* For Internet Explorer: <http://www.mlsecurity.com/ie/ie.htm>
http://www.mlsecurity.com/ie/ie.htm
* For Opera: < iframe name="abc" src="file:///C:/"></iframe>
ADDITIONAL INFORMATION
The information has been provided by <mailto:mindwarper_@_linuxmail.org>
Mind Warper and <mailto:thor_@_pivx.com> Thor Larholm.
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.
- Previous message: SecuriTeam: "[TOOL] Btscanner - Bluetooth Scanner"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
