httpd-dev mailing list archives

The sucgi wrapper is too simple.
Hmmm... before things get too heated, I'd better substantiate this
with an example of an attack which, I think, would work with the
sucgi wrapper, even after we tossed in Nathan's "owner == uid to
switch to" check. On hyperreal, which is a reasonably well-managed
system (as I recall, Satan gave it a completely clean bill of health
the first time Brian ran a check), we find the following:
taz-rst {106} ls -l /bin/chmod
-r-xr-xr-x 1 bin bin 1520 Feb 3 1995 /bin/chmod
taz-rst {101} ls -l /bin/cp
-r-xr-xr-x 1 bin bin 12288 Feb 3 1995 /bin/cp
taz-rst {102} ls -l /bin/ls
-r-xr-xr-x 1 bin bin 12288 Feb 3 1995 /bin/ls
So, anybody with who can arrange for the code of their choice to be
run by 'www' (by putting up a non-suid CGI script, putting a trojan
horse in the path of a maintenance script, or any other approach)
can prepare a trojan-horse version of 'ls', and then install it
as follows:
sucgi-wrapper bin bin /bin/chmod 0755 /bin/ls
sucgi-wrapper bin bin /bin/cp cp my-trojan-horse-ls /bin/ls
sucgi-wrapper bin bin /bin/chmod 0555 /bin/ls
The next time root runs 'ls', the gates are open.
(Going through the sucgi-wrapper security checks one at a time: the
guy's found a way to run this as "nobody" or "www" by hypothesis. The
third argument (name of target) is an absolute pathname, the target
user is not root, and *is* the owner of the program to be run.
Preserving last-modified date, length, and checksum of 'ls' is
possible, but more complex; however, technology for all of that is
well known and widely available in the cracker community. Preserving
a cryptographic checksum is harder, and probably requires subversion
of the program that computes the checksums).
This does require a cracker with more intelligence and
resourcefulness than the garden variety "install root-kit, if that
fails, go elsewhere" loser, but they're out there --- for one thing,
they're the ones that *write* the root-kits.
rst