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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <8B32EDC90D8F4E4AB40918883281874D0BAEFF@pivxwin2k1.secnet.pivx.com>
Date: Thu, 30 Oct 2003 14:30:00 -0800
From: "Thor Larholm" <thor@...x.com>
To: "Paul Szabo" <psz@...hs.usyd.edu.au>,
	<bugtraq@...urityfocus.com>, <full-disclosure@...ts.netsys.com>,
	<was@...romedia.com>
Subject: 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/


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ