msie4-persistent-connect.txt

`Date: Fri, 22 Jan 1999 14:15:32 -0600  
From: Joel Moses <[email protected]>  
To: [email protected]  
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 <[email protected]>  
To: [email protected]  
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 ([email protected])  
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.  
  
`