Date: Fri, 22 Jan 1999 14:15:32 -0600 From: Joel Moses To: BUGTRAQ@netspace.org Subject: IE4 Persistent Connection Bug Hi, everyone. Working with MCI/WorldCom, we've identified a problem with IE 4 which may or may not have security implications, but is definately naughty behavior, in our opinions. The document below details a connection-reuse problem which uses persistent connections even when they have either 1) been specifically disabled, or 2) have been told to close by a server "Connection: close". Those of you who use Linux Weekly News (http://lwn.net/) through some proxy servers and view it in IE 4 may experience a dropped connection when clicking on external URLs, which are linked through a cgi-bin redirector. This is one manifestation of the bug. Anyway, read through the article below, try it yourselves, and let me know what YOU see. Joel Moses Nashville, TN -------------------------------------- ISSUE: IE 4 Persistent (Keepalive) Bug PLATFORMS: Microsoft Internet Explorer 4.0 (all service pack levels) Windows 95/98/NT confirmed, others possible Internet Explorer 5 has not been tested SYNOPSIS: Microsoft Internet Explorer 4.0 ignores certain HTTP/1.0 instructions, preferring instead to behave in the HTTP/1.1 style, even when HTTP/1.1 capability is specifically disabled in the browser. The primary way this problem manifests itself is through proxy connections. DETAILS: First, some background: RFC-2068 (HTTP/1.1) states that connections are assumed to be persistant unless explicitly closed. HTTP/1.0's behavior is that persistent connections must be negotiated, otherwise they should be closed as a matter of course. Many proxy servers do not implement HTTP/1.1 persistent connections, so an option was added to IE 4 to disable HTTP/1.1 features through proxy connections. It appears that some features are indeed disabled (redirections, for example), but the behavior of the client regarding persistent connections is, in fact, still enabled. To demonstrate the problem, set up a "netcat" session on a specific port and point IE 4 to it as a proxy. Issue a page request, and then manually enter a response and data. The result will appear like this (user-entered data is in quotes): ------------------------------------------------------------------ $ nc -p 9000 -l GET http://www.somesite.com/ HTTP/1.0 Accept: image/gif, image/x-bitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 4.01, Windows 95) Host: www.somesite.com Proxy-Connection: Keep-Alive "HTTP/1.1 200 OK" "Connection: close" "Content-Length: 5" "abcde" ------------------------------------------------------------------ The browser will display "abcde," and the IE logo will stop circulating. However, the connection will not -- as requested by the server -- close. If you issue another page request in the browser for a different site, the request will come through on this previously-opened connection, e.g.,: ------------------------------------------------------------------ GET http://www.othersite.com/ HTTP/1.0 Accept: image/gif, image/x-bitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 4.01, Windows 95) Host: www.othersite.com Proxy-Connection: Keep-Alive ------------------------------------------------------------------ This clearly violates HTTP/1.0 behavior, with which the browser reports to the server that it complies. Netscape 4.x behaves correctly and closes the connection itself when faced with the same situation. RISK: These are only possible risks. YMMV. This bug could potentially be exploited to allow an external agent to proxy traffic for a user without that user's knowledge. There are two different situations at play here. 1) User sits behind a firewall or proxy (corporate network, etc.) Be aware that IE 4's default behavior is to disable HTTP/1.1 and masquerade as an HTTP/1.0 browser when utilizing a proxy connection. If the proxy the user is connecting through does not check and block traffic whose base host changes, any traffic sent out would keep the existing connection alive to allow an external host to act as a proxy itself. For example, USER issues page request for SITE 1. CLIENT connects to PROXY to issue the request. The PROXY initiates a connection to SITE 1, SITE 1 returns its data, and the BROWSER does not drop the connection to PROXY. USER issues page request for SITE 2. CLIENT uses the still-open connection to PROXY and requests SITE 2. PROXY has maintained a connection to SITE 1 and does not distinguish SITE 2 is a different site. SITE 1 recieves a request for SITE 2. At this moment, SITE 1 could potentially position itself as a proxy, connecting to SITE 2 and relaying the information back to the browser. SITE 1, in effect, becomes a man-in-the-middle. The only proxy I have tested thus far is the InterLock. It is not vulnerable because it closes the connection when the site changes unexpectedly. I have not been able to verify whether other proxies are affected. Please note that this behavior would only occur if the proxy server DOES NOT reject persistent connections which change their Host: header suddenly and unexpectedly, but, rather, forward all transmissions to the endpoint regardless of URL. 2) User has explicitly disabled HTTP/1.1 but does not sit behind a firewall or proxy. This case is similar to the above scenario, in that a connection to a Web server would tend to remain open even after the "Connection: close" is sent. This existing connection would then be automatically re-utilized by the browser for any subsequent request, even to a different site. It is possible that a modified version of Apache could use this type of re-utilized connection to forward and view traffic from the browser. SOLUTION: Administrators should test their own proxy servers for this problem and alert the vendor if necessary. Microsoft has not, to my knowledge, released any fix for IE 4. The latest service pack, version 1A, is still affected. _They have been notified_ regarding this issue and have thus far not acknowledged this session-level behavior as being incorrect. ACKNOWLEDGEMENTS: Thanks to Justin Dolske at MCI/WorldCom who initially identified this as a bug in IE 4. ----------------------------------------------------------------------------- Date: Mon, 25 Jan 1999 16:53:30 -0500 From: Justin Dolske To: BUGTRAQ@netspace.org Subject: Re: IE4 Persistent Connection Bug On Mon, 25 Jan 1999, Drazen Kacar wrote: > > The browser will display "abcde," and the IE logo will stop > > circulating. However, the connection will not -- as requested by the > > server -- close. If you issue another page request in the browser for > > You mean "as requested by the origin server." Connection header is hop-by-hop, > which means that it has a meaning for a connection between origin server > and proxy server only. I included this in my original example just to clarify that MIE shouldn't be attempting to make a persistant connection "through" the proxy. This header is not needed to cause the behaviour in question, however. > It doesn't. Your netcat "proxy" violates it. Here's a quote from RFC 1945: > > Except for experimental applications, current practice requires that > the connection be established by the client prior to each request and > closed by the server after sending the response. Yes, but that doesn't address what the client should do if it wants to send a second request but the connection has not yet closed. Consider that network latency may result in the server's/proxy's FIN being delayed -- the client would still send the request, even though the connection is being closed. From the client's point-of-view, it can't tell the difference between a delayed close and netcat not closing the connection at all. The point is not who should be closing the connection, but that MIE is sending a second request over a connection that has not been negotiated to be persistant. Justin Dolske (dolske@reston.wcom.net) MCI WorldCom Advanced Networks Interlock Firewall Development -=-=-=-=-=-=-=-=-=-=-=-=-=- Random Sig-o-Matic (tm) -=-=-=-=-=-=-=-=-=-=-=-=- Windows 95: n. 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition.