The Microsoft IIS Bug
My chronicle of finding a most embarrassing bug
by Todd Fast
________________________________________________________
The Story
My name is Todd Fast, and I found a bug today. I found it while trying
to determine the maximum length of a URL Microsoft's Internet
Information Server (IIS) would accept without an error. This website
is dedicated to this bug and my chronicle of it.
In case you haven't heard the details, there's a bug in Microsoft's
Internet Information Server on Windows NT (and possibly other
platforms) that allows a remote user--any user--to shut down the web
server, and consequently the web site, using nothing more than a web
browser.
This is a hugely embarrassing bug for Microsoft in my opinion,
particularly since they've just been lauded for pulling ahead of
Netscape in Web server market. Knowing that anyone with a grudge and a
twitchy keyboard could shut down any of their customer's web sites
must bear horribly on their collective conscience. (Ask yourself, was
that sarcasm?)
The Bug
I know you can't wait to know more, so here are the nitty-gritty
details on the actual bug, from the original message I sent to
InfoWorld:
I've found a severe bug that allows any remote user on the Internet to
halt web services on an Microsoft NT 4.0 server running Microsoft's
Internet Information Server version 3. This bug appears to unaffected
by the installation of Service Pack 3.
Let me explain the details of the bug and how I came across it. The
bug surfaces when a remote user requests a Web URL from the IIS server
that contains a certain number of characters (I'll call this number
the "bug threshold") and is of the following form:
http://<some web server>/?something=XXXXXXXX...
To cause the fatal error, this URL should contain a CGI name/value
pair of a certain length. Note that the user does not have to request
any specific document: the error occurs because of the length of the
URL alone. Apparently, this bug only appears when using Netscape
Navigator to contact the server because Internet Explorer won't allow
such a long URL to be sent.
The length of the URL required to cause a crash is specific to each
server, but seems to hover around 8K. Finding the correct length to
kill an IIS server requires trial and error. I've found that URLs
above the bug threshold return a "404 Object Not Found" or similar
error. Below the threshold, the requested page loads properly.
However, sending a URL who's length is exactly the bug threshold
causes the server to stop responding.
When a user sends this URL to an IIS web server, it causes an access
violation in the INETINFO.EXE process. We don't know what this small
8k process's role is in the server's operation, but when it fails, it
causes the WWW service under IIS to stop. The site administrator must
then clear the error and restart the service to continue operation.
The bug does not always appear upon the first document request, but
repeated application will eventually cause INETINFO.EXE to fail.
A colleague, Bill Chaison, has studied the Dr. Watson log file and
offers more information on the location of the error in the
INETINFO.EXE process:
"This particular GPF occurred at 0x77A07614 on our server. The
offending application is INETINFO.EXE, one of IIS 3.0's components.
The stamp properties of our EXE are DATE=08/09/96, TIME=01:30a,
SIZE=7440 bytes. Referencing the dump, thread ID 0xF9 performed a
string compare function which caused a read fault during an iteration
of the CMPSB (compare string byte by byte) opcode. This opcode works
off of ESI and EDI as its base pointers and ECX as its loop repeater.
I suspect that either ECX was either miscalculated to begin with, or
ESI or EDI went out of range and caused a protection exception. The
Watson error dialog reflected 0x77A07614 as the CS:EIP of the fault
when the message box popped up. The log file below confirms the
address of the error. Search the file for "FAULT ->" to jump to its
description."
See the attached file IISCRASH.TXT file for the stack dump.
I discovered the bug while trying to determine the maximum length of
the URL IIS would accept. While doing so, I found that our in-house
server stopped responding. Not realizing that this was a bug that
affected all copies of IIS, I continued my investigation using
Microsoft's site, www.microsoft.com, and inadvertently shut down their
web server as well. At this point I realized that the error was indeed
a bug that affected IIS itself.
To my knowledge, this bug has never been exploited or been used to
crash or deny service from any web site. However, just because I spoke
up about it doesn't mean that someone else hasn't already found or
been using it. All you webmasters out there using IIS, have you had
any strange crashes lately?
Are you a CyberTerrorist?
If so, please don't start your own CyberJihad by downloading the
following program and easily reproducing this bug on any number of IIS
servers all over the Internet. The Internet Worm was bad enough, and
that is not my intent.
I'm making this program available so that those of you running IIS can
more easily assess your web server's vulnerability and whether this
bug would do anything more than deny your customers service (as if
that's not bad enough).
Remember this program doesn't do anything special or sneaky, it just
makes the job of finding the already-existing bug on a particular
server somewhat easier. It does nothing that someone couldn't do in
about 5 minutes with a browser anyway, so please, no hate mail from
webmasters for making it available. Instead, blame Microsoft's bug.
Here are the details:
I created a small Java program, called IIServerSlayer, that repeatedly
hits a web server with a varying length URL until the web server stops
responding due to the IIS bug. To run the program, first ensure that
you have Java 1.0.2 installed on your machine and running properly.
Put the IIServerSlayer.class file in a directory and open a command
window located at that directory. Use the following command line:
java -classpath .;%classpath% IIServerSlayer <some IIS web server>
<starting URL length>
We use a starting URL length of between 8200 and 8300 to crash our
server, but one of our servers crashed in a much lower range of around
4000 bytes. Trial and error is the only way to determine the threshold
and I suggest starting at a length of 8300. Also, don't use http:// in
front of the server name; the program does that for you.
One of the things to note about the program is that it can't really
detect if the web request is being served properly. Because the bug
doesn't always surface on the first document request with the
problematic URL, the program only decrements the length counter if an
error occurs, but assumes that server is about to crash if an error
doesn't occur and the counter has remained the same. This means that
if you start the program and don't see a series of lines like the
following:
Trying length xxxx...Done
Trying length xxxx...Done
Trying length xxxx...Done
...
and instead see this:
Almost dead! Retrying length xxxx...Done
Almost dead! Retrying length xxxx...Done
Almost dead! Retrying length xxxx...Done
you have started with too low a URL length and need to Ctrl-C the
program and restart it with a higher length. When the program pauses
for more than a few seconds on a particular statement, you can be sure
that the web server has died. When you go to the web server and clear
the error, IIServerSlayer detects that the error occurred and gives
you a message stating so.
Download a copy of IIServerSlayer for personal, non-malicious use
Chronicle
Because the Internet's relevance to our existence is access to timely
information, I'm posting the chronicle of my experience with this bug
below in as close to real time as I can. I don't know whether it will
turn out interesting or not, but there's no way to tell until I try
it.
6-19-97
~3:30 PM CST I contact News Editor Michael Parsons at the trade
publication InfoWorld and tell him a strange story of a bug I've found
in IIS that allows any remote user to shut down an IIS web server.
Michael sounds keenly interested and I promise to send him additional
information and the program I've written to reproduce the bug shortly.
About 20 minutes later I send the email.
6-19-97
4:45 PM CST Jon P. at Microsoft calls to ask about the nature of the
bug. He sounds nervous to me and wants to get straight to the point. I
tell him that I'll send along the email I sent to InfoWorld along with
the program. He sounds skeptical, but accepts. He seems to think that
this is probably a bug Microsoft has already addressed in a service
pack or a hotfix. I'm not so sure. Let's wait and see.
6-19-97
~5:15 PM CST Maggie Biggs at InfoWorld calls to ask some additional
questions about the bug for an upcoming news release. She says she's
been able to reproduce the bug and wonders how it may affect other web
services in IIS like FTP. I agree to send my program to her so she can
use it to reproduce the problem. She's very friendly and helpful.
6-19-97
5:40 PM CST Maggie Biggs at InfoWorld emails to tell me she's
reproduced the problem on her test machines and will be assessing the
bug related to other World Wide Web services under IIS. She's stated
that one of her test machines crashed altogether, a situation she's
called "potentially...quite serious".
6-19-97
5:55 PM CST News is spreading like wildfire. Another journalist at
InfoWorld in Seattle calls and interviews me on the phone about the
nature of the bug. He asks if the bug would occur during normal usage
of the server and I said it probably would not due to the length of
the string.
More Info?
As more information on this problem comes to light, I'll post it here.
Keep coming back to check out the latest news.
What's with the name?
I named this website after the title of this message from an old
friend, upon hearing the news:
"You're walking the fine line between info-terrorist and "just another
guy looking to help mankind". Here's a tip: if you'd like to be
labeled info-terrorist, send an e-mail to Microsoft like those Danish
guys that found the Netscape security flaw. I think the e-mail
actually said, "OK, where's the guy with the checkbook". Then you
could adopt some crazy online name like 'LordChaos' or 'DethKing' like
those Undernet software pirates do.
"P.S. If this blows up and I get interviewed, you can count on me
saying all kinds of awful stuff: 'He was a loner. He read Soldier of
Fortune a whole lot.' Then I'd throw in a curveball to make people
really wonder: 'He would get really upset whenever 'The Tick' episode
was a rerun and would launch a new computer virus".
I promise it's not all true.
Parting Words
A colleague had the good sense to remind of something I'd almost
forgotten before today:
You get what you pay for
Copyright C 1997 by Todd Fast. All rights reserved.
Contact the author, Todd Fast, at tfast@eden.com