httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From (Robert S. Thau)
Subject Re: setuid control WITHOUT running as root
Date Sun, 02 Jun 1996 23:44:26 GMT
  No.  sucgi-wrapper will not execute an argv0 with leading slash.
  Unless you can place a CGI file in a directory owned by bin
  and make the CGI owned by bin, the server will not execute it.
  If you are running a "non-suid" CGI script, the server will
  not use the wrapper.

Fine --- the attack has to look like this:

  cd /bin
  sucgi-wrapper bin bin chmod chmod 0755 ls
  sucgi-wrapper bin bin cp cp /wherever/my-trojan-horse-ls ls
  sucgi-wrapper bin bin chmod chmod 0555 ls

The wrapper here is being 'conned' into executing chmod and cp.
It does *not* check that the owner of the directory is the same
as the owner of a script --- that check may be performed by your
code inside the server, but whatever checks are performed inside
the server are, as I said before, irrelevant.  And even if sucgi
did do that check, /bin might well be owned by the 'bin' user.

(By the way, checks like this get a whole lot easier to subvert on
Unix variants which allow users to give away files that they own to
the victim of their choice.  These chowns always reset the suid bit,
precisely to keep a malicious user from using such a 'gift' as a
trojan horse.  However, if the web server is running CGI scripts with
the uids of their owners, that check suddenly stops working so well,
*unless* the web server has checks which are sufficient to keep such a
"gift file" from ever being invoked as a CGI script --- cgiwrap seems
to do a pretty good job of this, FWIW).

And yes, I *am* assuming the attacker has found a way to run
the shell script above (or equivalent perl code, or whatever) 
under the 'www' uid --- perhaps he has permission to install
non-suid cgi scripts, which run with that uid; perhaps one of
them is sloppily written, and can be coerced into running trojan
horses of its own (such staged trojan-horse attacks are fairly 
common ways to crack a system), and so forth.

My point is that once sucgi-wrapper, as currently written, is
installed suid-root on a system, subverting the 'www' uid becomes
only an easy hop, skip, and jump away from subverting root.
It's a bad idea to deploy a security scheme which has this 
property for the same reasons it's a bad idea to run the server
with "User root" in the first place.

In short --- sucgi-wrapper needs to get more paranoid before I
think it's really safe.


View raw message