Securing cgi scripts

Matthew Seaman m.seaman at infracaninophile.co.uk
Fri Jan 22 17:14:59 UTC 2010


DAve wrote:
> Good morning all,
> 
> I have been working on an issue here where I am being asked if we can
> support letting clients install and run their own CGI scripts on a
> shared vhost. I have tried sbox and cgiwrap, both which worked, but they
> cannot stop the one test of reading the /etc/passwd file.
> 
> Forgive my ignorance here, but I thought CGIs were gone long ago and
> have not messed with them in over ten years. If a client really needs a
> specfic CGI script hosted, I check it out thoroughly and install it
> where they cannot reach it. Those instances are very very rare.
> 
> It looks to me like the only way to keep a client contained is to run
> their CGIs chrooted. Would this be correct?

CGI programs run in the OS filesystem context, so there's generally nothing
to stop them reading /etc/passwd.  They are essentially the same level of
risk as an unprivileged user login account.  

Mind you, pretty exactly the same thing applies if you let your customers
supply their own PHP or perl or other programs which run using an interpreter
embedded in the apache process: they can access anything accessible to the
web server process.  

I should point out that unprivileged users are *meant* to be able to
read /etc/passwd -- it's /etc/master.passwd that has the sensitive stuff
in it.

In fact, the bigger problem with running CGI programs from a shared
webserver is that they generally all run using the same security
credentials; those of the web server (www:www by default) -- which
potentially lets all your different customers tread on each others toes.  suexec(8) is the stock solution to that problem.

If you really want to keep your customers properly separated, then send
them to jail(8).  While giving them each a separate jail with a full 
install of apache etc. certainly does work, it implies dedicating at least
an IP per customer.  You could avoid that by still keeping a single apache 
instance but use something like an fCGI process per customer running each in 
separate jails hanging off the loopback i/f.

	Cheers,

	Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.                   7 Priory Courtyard
                                                  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey     Ramsgate
                                                  Kent, CT11 9PW

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 259 bytes
Desc: OpenPGP digital signature
Url : http://lists.freebsd.org/pipermail/freebsd-questions/attachments/20100122/a48668fd/signature.pgp


More information about the freebsd-questions mailing list