mirror of
https://github.com/opsxcq/mirror-textfiles.com.git
synced 2025-08-11 00:44:13 +02:00
146 lines
9.3 KiB
Plaintext
146 lines
9.3 KiB
Plaintext
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.
|
|
|
|
|
|
|
|
|
|
|