"Richard Smith" writes: > Is it possible to also crash a Web server hosted on a Windows box using > a URL something like: > > http://www.somebody.com/aux > > If this particular URL is okay, maybe there are other URLs that will > cause a crash. For example, POSTing a form to a URL containing AUX. > > This problem could be in any Windows Web server such as IIS, Apache, > ColdFusion, etc..
IIS wasn't ever vulnerable to this to my knowledge -- it certainly is not now. Apache suffered this vulnerability prior to 2.0.44 -- it doesn't even have to be a POST if the server is vulnerable, a GET will hang it: GET /aux HTTP/1.0 The attack does not get logged if it is successful, as the server is usually dead before the request finishes. If the server supports POST, there is a possibility for remote code execution. Specifically, if the server supports POST and offers one or more script-mapped CGI's (e.g, something that doesn't rely on the "#!" 'shebang' line to determine the interpreter. If you are to POST: POST /con.pl HTTP/1.0 Content-Length: 21 Content-Type: application/x-www-form-urlencoded print "Hello World!"; And the server is vulnerable to the reserved device attack, it will issue: perl.exe con.pl The 'con' reserved device may point to the interpreter's STDIN, and for those of us not familiar with CGI, STDIN contains the user-specified request body. This effectively causes the interpreter to execute the user-supplied form body. The details of this vulnerability in Apache 2.0: CERT VU#979793 - Apache Vulnerable to DoS Via Request for DOS Device http://www.kb.cert.org/vuls/id/979793 CERT VU#825177 - Apache Allows Arbitrary Code Execution Via Crafted POST Containing MS-DOS Device Name http://www.kb.cert.org/vuls/id/825177 CVE Candidate CAN-2003-0016 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0016 I have also witnessed other applications for this vulnerability than on web servers. Any system that allows user-input to become part of a file name could be crashed with this vulnerability. This includes various servers -- I've seen SMTP, TFTP, POP3, and FTP servers that are impacted by this, and I'm sure the list could get much longer. Virtual machines (e.g, Java) may want to watch for this exploit on Windows systems, as it can appearantly cause far-reaching damage. After I investigated the scope of the Apache issue, I found these other potentially impacted services. I was *NOT* able to cause IE to fail on the machine where the Apache issue was uncovered. However, with this additional find, it does appear that this is a vulnerability in the Windows kernel, not the individual applications. It appears that the reason I was initially unable to reproduce this vulnerability in the way the original poster described was because entering "C:\AUX" into IE in Windows Me/XP/2003 simply causes the "Choose Application" dialog box to appear. Had I entered "C:\AUX.HTML", perhaps, the crash would have occurred as intended. Also, had I chosen an application to open the file, that program most likely would have frozen. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html