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

[dfd <dfd@xxxxxxxxxxx>]

>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