Message-ID: <41B1FD84D49E05448A4233378E6BF47501F4A902@entmsgnt03.fm.frd.fmlh.edu>
From: jheidtke at fmlh.edu (Jerry Heidtke)
Subject: RE: Internet Explorer and Opera local zone restriction bypass

Thor,

You say "there is absolutely no reverse-engineering that will convince IE to render a BAE-64 encoded string as HTML." I'm assuming you mean IE can't render base64 into understandable html.

On the other hand, there's this statement from Microsoft (http://msdn.microsoft.com/ieupdate/activexchanges.asp) showing how to use base64 to feed data to an ActiveX control.

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

You can provide base64-encoded data to the ActiveX control with the DATA attribute of the OBJECT element to provide data in base64 format. The base64 format is a representation of your data in a numbering system with 64 possible digits. You can find an application to convert your data to base64 by searching the Internet (this BASE64/RADIX64 Coder  is one example). Any data provided with the DATA attribute is available at control initialization time. The following example shows how to provide initialization data to an ActiveX control with the DATA attribute.

<OBJECT ID="myCtrl" WIDTH=50 HEIGHT=50
    CLASSID="CLSID:37C9CF72-E47F-445d-9228-AD1CA6398442"
    DATA="DATA:application/x-oleobject;BASE64,j43aWGqdGxCvwEIQ">
</OBJECT>
Additionally, base64 data can also be provided with a PARAM element. Use a PARAM element as a child of an OBJECT element. Set the VALUE attribute equal to the base64 data you want to provide to the control. Data provided with a PARAM is not available until after the control has been initialized. The following example shows how to provide inline data to an ActiveX control with a PARAM element.

<OBJECT ID="myCtrl" WIDTH=50 HEIGHT=50
    CLASSID="CLSID:37C9CF72-E47F-445d-9228-AD1CA6398442">
    <PARAM 
        NAME="myParam" 
        VALUE="DATA:application/x-oleobject;BASE64,j43aWGqdGxCvwEIQ"/>
</OBJECT>
To be treated as inline data, the format of any DATA:uri must match the format of the PARAM element's VALUE attribute in the previous example.

Decoded data is available to the control as a stream by using the IPropertyBag::Read method in the form of an IUnknown interface, which can be queried for an IStream using QueryInterface. If the VARIANT passed to the IPropertyBag is initialized as a BSTR, the raw value may be obtained.

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

I'm no expert in these matters by any means, but it appears that IE can quite easily interpret base64-encoded data and act on it. I can't say whether this has any bearing on the exact issue with Flash, but it might be worth considering.

Jerry

-----Original Message-----
From: Thor Larholm [mailto:thor@...x.com]
Sent: Thursday, October 30, 2003 4:30 PM
To: Paul Szabo; bugtraq@...urityfocus.com;
full-disclosure@...ts.netsys.com; was@...romedia.com
Subject: [Full-Disclosure] RE: Internet Explorer and Opera local zone
restriction bypass


> From: Paul Szabo [mailto:psz@...hs.usyd.edu.au] 
> Storing in an unpredictable location might help. 
> Obfuscation does not: instead of setting a cookie 
> of BadThing, the attacker could set one that will 
> become BadThing. The need to reverse-engineer the 
> obfuscation, and details like possible character 
> sets, are a minor hindrance only. 
> 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/

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Confidentiality Notice: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and may contain
confidential and privileged information.  Any unauthorized review, use,
disclosure or distribution is prohibited.  If you are not the intended
recipient, please contact the sender by reply e-mail and destroy all
copies of the original message.

Powered by blists - more mailing lists