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.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:29:52 PDT