[<prev] [next>] [day] [month] [year] [list]
Message-ID: <8B32EDC90D8F4E4AB40918883281874D03ED2A@pivxwin2k1.secnet.pivx.com>
From: thor at pivx.com (Thor Larholm)
Subject: RE: Internet Explorer and Opera local zone restriction bypass
Jerry,
These are completely different things, despite the apparent similarity. What Microsoft is stating is that you can take an ActiveX control and embed it inline in an HTML document as a BASE-64 encoded string, e..g
<OBJECT ID="myCtrl" WIDTH=50 HEIGHT=50
CLASSID="CLSID:37C9CF72-E47F-445d-9228-AD1CA6398442"
DATA="DATA:application/x-oleobject;BASE64,j43aWGqdGxCvwEIQ">
</OBJECT>
To even activate the above embedded BASE-64 decoding of ActiveX components, you have to let IE render some HTML in the first place which contains an OBJECT tag with the BASE-64 encoded data specified inline.
However, what we are trying to achieve here is to have IE render some arbitrary file as HTML. in the first place To do this, we need to store plaintext HTML in the first 256 bytes of some file, which the Flash vulnerability allows us to do. If Flash stored its data BASE-64 encoded, then IE would no longer be able to render the .SOL file as HTML, and this exploit would no longer work.
Again, these are completely different parts of IE, determining HTML file loading versus inline BASE-64 decoding of embedded ActiveX components. You can read more about how IE determines how it should render a file in the article "MIME Type Detection in Internet Explorer " at
http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp
This is not to say that there is not any issues with inline BASE-64 encoding of data in IE, but determining whether to render a file as HTML or not in the first place is not one of them. Nice catch, though :)
Regards
Thor
-----Original Message-----
From: Jerry Heidtke [mailto:jheidtke@...h.edu]
Sent: Thu 10/30/2003 5:04 PM
To: Thor Larholm; Paul Szabo; bugtraq@...urityfocus.com; full-disclosure@...ts.netsys.com; was@...romedia.com
Cc:
Subject: RE: [Full-Disclosure] 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
Powered by blists - more mailing lists