full-disclosure - Does the Windows AUX bug affect Web servers also?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

From: mattmurphy at kc.rr.com (Matthew Murphy)
Subject: Does the Windows AUX bug affect Web servers also?

"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.