[cobalt-security] Re: Re: SSI Vuln on cobalt

[Chris Adams <cmadams@xxxxxxxxxx>]

Once upon a time, Jeff Lasman <jblists@xxxxxxxxxxxxx> said:
> Chris Adams wrote:
> > Once upon a time, Gerald Waugh <gwaugh@xxxxxxxxxxxxxxxxxxxxxxx> said:
> > > SSI is not CGI, turn SSI off, its in the GUI site-settings
> > > Uncheck          Enable Server Side Includes
> > 
> > And, as I've pointed out before, all of those cute little checkboxes are
> > useless.
> 
> I wouldn't call them "useless"; I'd call them an easy way for a RaQ
> admin to turn features on and off for the great unwashed masses <grin>.

Turn them on: yes.  Turn them off: not really. :-)

> > AddHandler cgi-script .cgi
> 
> Of course this could be a security hole for the RaQ...

Remember when they changed the ownership of all the FrontPage sites with
a security patch?  Now you know why. :-)

Like I said below, I think that this may also be a security hole that
would allow any site admin to get any other site's SSL private key.  I'm
not sure (I haven't checked into it carefully), but I believe it is
possible.  If nothing else, a user could have a CGI that copies /bin/sh,
chowns it to the Apache user (httpd), and setuids it.  Then they can run
stuff as user httpd at will, including a debugger on the Apache
processes.  At that point, there are all kinds of possible holes
(interfering with other web sites, reading SSL keys, etc.).

> > IIRC, you can even load mod_perl handlers into the web server (which may
> > open up things such as the SSL private keys to all hosted sites - I
> > haven't tried it, but it should be possible since mod_perl runs in the
> > server space).
> 
> No different than any other linux-based hosting platform, really.

Well, I don't configure my Apache with "AllowOverride All".  I also use
the Apache built-in suexec, which runs for _all_ external calls (CGI and
stuff called via SSI).

I also don't configure mod_perl into servers where users have access.

Those two things mean that users can't cause things to run as any user
other than themselves, which goes a long way towards securing the
system.

> For exmaple, if we create a root-owned .htaccess file, then site admins
> can't easily install their own.

Since they own the directory (and have to, to create files), they can
remove any .htaccess file root creates.
-- 
Chris Adams <cmadams@xxxxxxxxxx>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.