Date: Fri, 22 Jan 1999 14:15:32 -0600
From: Joel Moses <jmoses@DTTUS.COM>
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 <dolske@reston.wcom.net>
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.