[15883] in bugtraq

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

Re: Cobalt RaQ 3 security hole?

daemon@ATHENA.MIT.EDU (Francis [loaded.net])
Fri Jul 21 15:30:58 2000

MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Message-ID:  <Pine.BSF.4.21.0007210808590.4508-100000@shell16.ba.best.com>
Date:         Fri, 21 Jul 2000 08:14:06 -0700
Reply-To: "Francis [loaded.net]" <francis@BEST.COM>
From: "Francis [loaded.net]" <francis@BEST.COM>
X-To:         Chad Day <cday@BEACHASSOCIATES.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <A8D9B16D2196D2118B6E00A0C9E307F4238680@beachpdc1.beachassociates.com>

If my experience of Cobalt RaQ's is anything to go by admserv needs root
permissions to execute some of the scripts that come standard with the web
interface. This allows designated user accounts to create new users in
/etc/passwd, and so fourth. The errors you are getting running it as an
ordinary user are due to insufficient privileges. Whilst running admserv
as root isn't perhaps that secure, it is essential to the function of the
web interface, one can only hope that Cobalts scripts that run through
admserv don't have any holes.

Thanks and best regards,
Francis


On Tue, 18 Jul 2000, Chad Day wrote:

> This may not be a true alert, I'm a bit of a newbie at security, but this is
> just screaming out to me.
>
> I'm working for a client on a freelance project who is running a Cobalt RaQ
> 3.  I needed to rebuild Apache to compile in PHP4 support.
>
> So, I do this, yadda yadda..
>
> The server is running 2 copies of apache.  The standard one on port 80, and
> "admserv" on port 81, which is the web administration interface.
>
> I take my newly compiled httpd, back up the old one in /usr/sbin, and
> restart both copies of apache.  The standard one comes up fine.  The
> "admserv" one refuses to start.
>
> [root@cb029 admin]# /etc/rc.d/init.d/admserv start
> Starting admin web server:
> Error:  Apache has not been designed to serve pages while
>         running as root.  There are known race conditions that
>         will allow any local user to read any file on the system.
>         If you still desire to serve pages as root then
>         add -DBIG_SECURITY_HOLE to the EXTRA_CFLAGS line in your
>         src/Configuration file and rebuild the server.  It is
>         strongly suggested that you instead modify the User
>         directive in your httpd.conf file to list a non-root
>         user.
>
>
> Obviously, running apache as root is a Bad Thing.  I check their
> configuration files, and sure enough the httpd.conf for admserv is set to
> run as root/root.  I change this, it starts up fine, but then the admserv
> interface breaks, with errors like:
>
> [Sun Jul 23 05:58:10 2000] [crit] [client xx.xx.xx.xx] configuration error:
> couldn't check user.  No user file?: /cgi-bin/.cobalt/backup/backupmenu.cgi
>
> Those errors do not appear if the webserver is running as root, which I put
> the old httpd back on and tested to verify.
>
>
> WTF?  Is it standard for Cobalt servers to compile Apache with the
> BIG_SECURITY_HOLE flag and run admserv as root/root?  Is this just a local
> issue, something whoever installed this on on the server did initially?  I
> obviously do NOT want to compile my copy of apache with BIG_SECURITY_HOLE
> just to get the admin interface working.  The only thing I can think of is
> changing the permissions on all the admin interface files to let another
> user execute the scripts, but is that going to open up something else?
>
> I highly suspect this is not an issue with all Cobalt RaQ 3's, because
> someone else would have had to come across this.  Can anyone clue me in on
> what I did wrong, if anything?
>
> Thanks,
> Chad
>

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