lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 30 Oct 2003 19:04:01 -0600 From: "Jerry Heidtke" <jheidtke@...h.edu> To: "Thor Larholm" <thor@...x.com>, "Paul Szabo" <psz@...hs.usyd.edu.au>, <bugtraq@...urityfocus.com>, <full-disclosure@...ts.netsys.com>, <was@...romedia.com> Subject: RE: 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. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Powered by blists - more mailing lists