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-prev] [thread-next>] [day] [month] [year] [list]
From: nick at virus-l.demon.co.uk (Nick FitzGerald)
Subject: RE: FWD: Internet Explorer URL parsing
 vulnerability

"Clint Bodungen" <clint@...ureconsulting.com> wrote:

> Well, using a straight link like the following works in an HTML email... but
> not on a web page:
> 
> <a href="http://www.microsoft.com%01@....linux.org">Microsoft</a>
> 
> However, using this approach still allows the user to see the absolute URL
> path in the task bar (with the %01 ommitted).

Not "omitted" but replaced with a (narrow) space.

The appearance of the absolute URL in the task bar is not a problem 
though.  Depending on how the URL is contained in the page this can be 
"fixed" with things such as "onmouseover" (one of the reasons the 
combination of such a "functional" DOM and scripting is pure evil...) 
and we have seen spammers do this already.  Of course, as the main 
concern here is only to fool IE users (almost a foregone conclusions 
because they _are_ IE users...) the old standard "obfuscate the URL in 
IE's task bar" trick of sticking a few dozen spaces after the spoofed 
domain and before the "@" (or before the "%01@" in this case) works 
just fine.

> On the other hand... using the button and "unescape()" approach such as the
> original example from this thread works from a web page but not from an HTML
> email.

Because you use a recent enough version of OE or Outlook which defaults 
to placing Email in the Restricted Sites zone which defaults to not 
allowing scripting...  Other MUAs dependent on IE's HTML rendering 
ActiveX controls may not be so forgiving and there are other ways to 
trick this out (see my forthcoming post about refreshes and the 
possibility of it working from server-side redirects).


-- 
Nick FitzGerald
Computer Virus Consulting Ltd.
Ph/FAX: +64 3 3529854


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ