[15907] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Cobalt RaQ 3 security hole?

daemon@ATHENA.MIT.EDU (Brian Behlendorf)
Sat Jul 22 17:54:38 2000

Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-Id:  <Pine.BSF.4.21.0007211701460.1193-100000@yez.hyperreal.org>
Date:         Fri, 21 Jul 2000 17:05:16 -0700
Reply-To: Brian Behlendorf <brian@COLLAB.NET>
From: Brian Behlendorf <brian@COLLAB.NET>
X-To:         Joshua Ellis <jellis@DSIGB.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <003a01bff290$e4465450$9914a8c0@sawing.com>

On Thu, 20 Jul 2000, Joshua Ellis wrote:
> That's the standard RaQ install.  If you do a /usr/sbin/http -V you'll see
> "-D BIG_SECURITY_HOLE".  It's how their mod_perl-based admin modules work.
> If you look in /usr/lib/perl5/site_perl/5.005/Cobalt you'll see they modify
> a lot of files writable only by root, and HUP a lot of processes owned by
> root... Apache has to be running as root for you to do that.

Not really true; one can write a setuid C program that sends a signal to
restart the Apache process, and is small enough to be (close to) provably
secure.  Small setuid binaries for other needs for root would be the way
to go.  One has to be careful to design it so that it can't be used for
other unsafe purposes, but that's far more containable than running Apache
as root.

	Brian

home help back first fref pref prev next nref lref last post