Bugtraq mailing list archives
Cobalt RaQ 3 security hole?
From: cday () BEACHASSOCIATES COM (Chad Day)
Date: Tue, 18 Jul 2000 21:12:18 -0400
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
Current thread:
- Cobalt RaQ 3 security hole? Chad Day (Jul 18)
- Re: Cobalt RaQ 3 security hole? Joshua Ellis (Jul 20)
- Re: Cobalt RaQ 3 security hole? Brian Behlendorf (Jul 21)
- Microsoft Security Bulletin (MS00-045) Microsoft Product Security (Jul 20)
- [ANNOUNCE] INN 2.2.3 available patrick () PINE NL (Jul 21)
- Re: Cobalt RaQ 3 security hole? Francis [loaded.net] (Jul 21)
- Re: Cobalt RaQ 3 security hole? Kurt Seifried (Jul 21)
- Re: Cobalt RaQ 3 security hole? Peter W (Jul 21)
- Re: Cobalt RaQ 3 security hole? Edward S. Marshall (Jul 24)
- Re: Cobalt RaQ 3 security hole? Wichert Akkerman (Jul 22)
- Re: Cobalt RaQ 3 security hole? Kurt Seifried (Jul 21)
- Re: Cobalt RaQ 3 security hole? Joshua Ellis (Jul 20)
- Sendmail filter rule to stop Outlook exploit Koos van den Hout (Jul 21)