IE4 Persistent Connection Bug

[jmoses () DTTUS COM (Joel Moses)]

     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.