Re: [cobalt-users] URGENT: Security hole in CgiWrap ?

["manitu" <manitu@xxxxxxxxxx>]

Hello,

I thank you VERY MUCH for this very detailed information!!!

Manuel



----- Original Message -----
From: dfd <dfd@xxxxxxxxxxx>
To: <cobalt-users@xxxxxxxxxxxxxxx>
Sent: Wednesday, March 08, 2000 11:25 PM
Subject: Re: [cobalt-users] URGENT: Security hole in CgiWrap ?


> >Hmmm. To be honest I don't know much about cgi wrapper. But if it is true
> >what you are saying, doesn't this open more ways for hackers to come into
> >your server if your clients are using unsecure scripts ? Perhaps they
don't
> >know about that and run their scripts as site admins who have some more
> >rights than simple users.
> >
>
> I'd recommend you have a look through the cgiwrap page to get a better
feel
> for the software's purpose.  It's at http://www.unixtools.org/cgiwrap/
>
> Basically without cgiwrap (or apache's solution, suEXEC -
> http://www.apache.org/docs/suexec.html) all CGI scripts on the server run
> as the user that is specified in apache.conf under the User directive, on
> the RAQ* this is the user "httpd".  All cgi scripts get the permissions of
> this user.
>
> An example of what's wrong with this:  We have a CGI script that takes
data
> from the web by a form and needs to store it in a file inside a certain
> directory.  For the httpd user to write to this directory, the directory
> needs to be either owned by httpd or give write permissions to other
users.
>  For example:
>
> drwxr-xrwx   7 dave     site75       1024 Oct 24 23:25 cgidata/
>
> This directory is read,write,execute to the owner user "dave", read and
> executable by site75, and any other user not in the site75 group has read
> write and exectute for that cgidata directory.  So we happily run our CGI
> without cgiwrap, and end up with files in that directory that are owned
> something like:
>
> -rw-r--r--   1 httpd    httpd         23 Jan 29 20:15 datafile1
>
> There are several problems with this, especially in a shared enviornment.
> If this is a machine with one site and one owner; you're all set - no real
> need for cgiwrap - it certaintly wouldn't hurt but it's less of an issue.
>
> However, in a shared enviornment, you face having a malicious user.  This
> user can do several things.  He can write a cgi script to modify the data
> stored in these directories or remove the files, since that cgi will be
ran
> as httpd and will have write permissions.  He can also write new files
> there which could cause problems.  Let's say that this directory wrote
news
> for a site and then it was included in when outputting a html page from a
> perl script.  The malicious user was just able to control the content you
> put on that site by changing those files with a malicious cgi script.  Any
> file or directory owned by httpd is fair game, he has total access, and
> this is where the problem lies in a shared enviornment.
>
> You can find what files and directories (respectively) are owned by httpd
> or are group httpd owned by:
>
> find / -type f \( -user httpd -o -group httpd \) -exec ls -ld {} \;
> find / -type d \( -user httpd -o -group httpd \) -exec ls -ld {} \;
>
> You may want to redirect this to a file:
>
> find / -type f \( -user httpd -o -group httpd \) -exec ls -ld {} \; >
> httpdlist
> find / -type d \( -user httpd -o -group httpd \) -exec ls -ld {} \;
> >>httpdlist
>
> Those are the files/directories that are potentially at risk if you run
> without cgiwrap.  That's not to mention files/directories writable by
> 'other' users:
>
> find / -type f -perm -002 -exec ls -ld {} \;
> find / -type d -perm -002 -exec ls -ld {} \;
>
>
> With cgiwrap, files are run wrapped setuid to the files owner (this means
> that they run as if the owner had ran them from telnet).  The same example
> above can now be made far more secure.  Our cgidata directory can be setup
> like this:
>
> drwx------   7 dave     site75       1024 Oct 24 23:25 cgidata/
>
> Now only dave can write to that directory.  When he creates files he can
> change the umask in his news cgi script to 077 (see "man umask") which
> would create files in this cgidata directory with permissions like:
>
> -rw-------   1 dave    users          23 Jan 29 20:15 datafile1
>
> Now the malicious user cannot even get into this directory, he cant modify
> files, and basically this is a more secure enviornment.  Giving anyone the
> permissions to run a file as a user other than themselves is where you
lose
> security on a *nix based machine, in my opinion.
>
> There's one pitfall and it's if you have PHP installed.  The default
> configuration is as an apache module and php scripts are not wrapped to
> that user.  This then creates the same security issue as CGI without
> cgiwrap.  You can use PHP in cgi form and then rely on cgiwrap, but you
> lose a good deal of functionality that I find useful with PHP.  There's
> also a safe mode feature of PHP (compile time option) that does attempt to
> help in this issue in module format).
>
> In summary, if you are using your machine in a shared hosting enviornment,
> you really need to use cgiwrap.  If you are concerned that the user that
> owns the scripts has too many permissions and shouldnt be running the cgi
> scripts, then I would suggest you create another user (with siteadmin)
> which you can then upload your scripts with.  Make sure to mkdir any
> directories that the scripts need to write to with this user.  Then remove
> the siteadmin permissions for this user.  Cgi scripts will run with that
> user's id without any special permissions.  If you have root on the
> machine, it's much easier, just chown the files to that user that you
> designate to be the cgi user and any files/directories that the scripts
> need to write to need to be chowned to that user as well.
>
> Also have a look at http://www.w3.org/Security/Faq/www-security-faq.html
> It's got a good deal of web security information including cgi scripts and
> is worth the read.
>
> - Dave
>
> _______________________________________________
> cobalt-users mailing list
> cobalt-users@xxxxxxxxxxxxxxx
> To Subscribe or Unsubscribe, please go to:
> http://list.cobalt.com/mailman/listinfo/cobalt-users
>