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.
Apparently, this bug only appears when using Netscape Navigator to contact the server...
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.