[661] in Intrusion Detection Systems
Re: Vulnerability of NCSA cgi-bin applications
daemon@ATHENA.MIT.EDU (Matt Willis)
Mon Mar 18 05:03:19 1996
Date: Wed, 13 Mar 1996 15:56:01 +0000 (GMT)
From: Matt Willis <willis@bliss.stetson.edu>
To: ids@uow.edu.au
In-Reply-To: <199603082343.SAA16728@bach.cis.temple.edu>
Reply-To: ids@uow.edu.au
On Fri, 8 Mar 1996, Alexander O. Yuriev wrote:
>
> I realize that that is not directly related to the mailing list, but it
> could be a useful way of alerting people who deal with intrusion detection.
> It just happened that a lot of WWW servers run by those people are affected!
> :)
>
> Alex
>
It does, however, leave a message in the httpd's access log. Everyone might
want to take a look through them.
> (This applies to *at least* the phf.c application as provided with NCSA
> httpd versions 1.3 and 1.5a-export; I've not inspected the other
> distributions yet.)
All cgi bin's compiled from the exampled source. It's sad that C code
that so poorly manages bad characters can make its way to such widespread
distribution.
>
> Many sites (I've looked around a bit and have had a hit rate of roughly
> 50% so far, but maybe I'm just "lucky")--including the top-level WWW
> servers for some large and/or very high-profile domains--appear to have
> "blindly" installed all of the cgi-src applications provided with NCSA's
> httpd. The most notable aspect of this particular cgi-bin
> vulnerability, at least to me, is not so much the vulnerability itself
> (it's been seen before) but rather its quite widespread nature.
>
No. It's more like 80%. NCSA and Apache are on a slew of systems.
> This vulnerability allows a remote client to retrieve any world-readable
> file from the server system, as well as execute commands and create
> files on the server with the privileges of the euid of the httpd server
> process.
>
> Depending on the server's (mis)configuration, this could conceivably be
> used as an avenue through which to replace the httpd server binary
> itself with a trojan--quite possibly to be run as root during the
> system's next boot cycle. It can also be used, largely independent of
> the server system's configuration--and rather easily--to gain remote
> interactive access to the server with the userid that the httpd server
> runs under. (I'm sure there are lots of other "nifty" possibilities,
> but I first found out about this a just few waking hours ago and have so
> far performed only the most basic proof-of-concept exploits.)
More accurately, make sure your httpd is running as 'nobody'. The exploit
I've seen has used 'cat /etc/passwd'. I pity you if you still have your
server running as root.
-Matt
Unix Admin for Stetson University (and stuff)
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: 2.6.2
mQCNAy/XticAAAEEAMb67/fXBbwyELgvHBw236fPDIUmZEe6ujMMpdkRLAjPCVF+
Z4Fu4XaPrgQEgURjI96G5HTTuj6sva9JsK9tZw/1KjxONYQDWeG2gC04Oh3vElB7
j1o+XNGhgVpctxVnjFO/6iLrlVOvQQBX9FJH4JCGfXjPmNYzZugnvgsVecr9AAUR
tCZNYXR0IFdpbGxpcyA8d2lsbGlzQGJsaXNzLnN0ZXRzb24uZWR1Pg==
=zD8e
-----END PGP PUBLIC KEY BLOCK-----
