Briefing #FR970616-1

The Microsoft IIS Bug

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:

IIS bug hotfix for Intel

IIS bug hotfix for Alpha

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 updated c|net and InfoWorld article for far less sensationalized accounts 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, until the update to the c|net article. InfoWorld was 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 (assuming the server is attended) 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 the original c|net article) by exploiting this bug unless there were an entire group of hackers or a single hacker with a program or script flooding Microsoft's site with damaging URLs to bring the web server to a halt as soon as it was restarted. It seems highly improbable that such an event occured and brought 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. (Actually, I've since found out that Microsoft patched their own site by 8:00 PM on Thursday--four to six hours after I told them about it.)

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.

I Want Your Feedback

As you can imagine, this little situation has evoked a great deal of opinion and commentary. I realized tonight that this is a singular opportunity to poll the public on their opinions regarding the seriousness of this bug, its appearance in software of this type, and the actions of the parties involved in reporting and responding to it. I'm interested in hearing from all of you, since I don't believe any information of this type has ever been publicly recorded or reported. I feel strongly that public opinion on this matter should be supported and published so that it may influence the reporting of and response to similar bugs in the future.

Please take a moment to fill in this questionnaire and let me know your opinions on this matter. If you'd like to hear back from me, please include your email address. If you check the box at the end of the questionnaire, stating that you'd like this information shared with the other involved parties, I will forward your repsonse on to the representatives of each party in which I have been in contact.

Note: By the way, this feedback form may not work properly with Microsoft's Internet Explorer if you are not using Microsoft Mail (I assume). I cannot confirm what configuration Internet Explorer must have to send a form from a web page via mail because I only use Eudora. If you are going to submit something here, it's best to simply email me directly or use Netscape Navigator.

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.

Please send any comments to Todd Fast

Copyright © 1997 by Todd Fast. All rights reserved.

End of transmission