full-disclosure - RE: FWD: Internet Explorer URL parsing vulnerability

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]

Message-ID: <3FD70352.20589.9A4BF6F0@localhost>
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