💾 Archived View for gemini.spam.works › mirrors › textfiles › hacking › MICROSOFT › iis.txt captured on 2022-06-12 at 08:48:47.
-=-=-=-=-=-=-
The Microsoft IIS Bug
(borrowed from the Jihad Site)
Latest on the Bug
I have voluntarily decided not to discuss specific information
relating to this bug for the time being. I'm posting here
Microsoft's patches for fixing the bug:
I have agreed to pull the details of the bug for several reasons,
none of which have to do with being threatened or being paid
off by Microsoft, as some of you have assumed or asked. I
haven't even been in contact with them since they've posted
the bug patches. They did offer me a t-shirt and "some free
software" for finding the bug, whatever that means. I may in
the future decide to repost the detailed bug information, but
for now am content to keep it private.
The Bug
I know you can't wait to know more, so here is some general
info 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.
<details omitted>
Apparently, this bug only appears when using Netscape
Navigator to contact the server...
<details omitted>
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 error dump.
I discovered the bug while testing IIS for a web development
project. 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
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.
Personal Commentary - Another
Explanation for Microsoft Being
Unavailable?
First, please let me stress here that I am a professional
software consultant, and in no way a "hacker" as some
coverage in the media has incorrectly stated. I feel I have
shown good faith by providing all the information I had about
the bug to an independant confirming source, InfoWorld, and
Microsoft within hours of discovering it. Please see the
InfoWorld article for a far less sensationalized account of this
event than you may find elsewhere. I originally contacted
InfoWorld to report this bug, and they are the only media
agency to which I contributed information. They were also the
first and only other party of which I am aware, besides
Microsoft, who were involved in confirming this bug.
The IIS bug, as Microsoft has corroborated publicly, is fixable
within seconds of it occurring. In my testing of the bug, it did
not crash the NT server or have any other effect on the server
or any of its running processes. In fact, the bug causes a single
process to have an access violation. After clearing the error
dialog, the administrator need only restart the WWW service
from the system tools shipped with Windows NT. This
process takes a maxmium of 15 seconds and can be repeated
any number of times without any additional effects. Microsoft
has also publicly corroborated that this bug causes no loss of
data, and thus, has no effect beyond the loss of service from
the web server temporarily.
It would have been impossible for "Hackers [to] jam
Microsoft's site" (as was the headline of a c|net article) by
exploiting this bug unless there were an entire group of
hackers working around the clock to bring Microsoft's site to
a halt as soon as it was restarted. It seems highly improbable
that a group of hackers suddenly exploited this bug to bring
Microsoft's site to a halt for a series of hours or days, as some
media coverage states, shortly after I discovered it. In
addition, Microsoft notified me that they had a fix for the IIS
bug available around noon on Friday. Were I Microsoft, and
my site was being supposedly jammed by hackers, I would
certainly have applied this patch to my website immediately,
which would have been, at latest, noon Friday.
Also, keep in mind that Microsoft has publicly stated that they
have been overwhelmed with Internet traffic and have been in
the process of upgrading their site over this last weekend. I
also have information from a kind reader that, if I understand it
correctly, he says shows that a significant cause of Microsoft's
site being down was related to a botched entry in the domain
name lookup system (perhaps because of the upgrade?). This
problem, as stated, essentially only allowed users to use a
single IP address, and thus a single server, to access
www.microsoft.com. As he put it, "Guess what happens when
everyone tries to use one server"? He says he contacted
Microsoft and notified them of the problem Friday, but
according to him, they didn't fix the problem until late this
weekend.