Cobalt RaQ 3 security hole?
Chad Day
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
Francis [loaded.net]
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
Joshua Ellis
> 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 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?
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. Unsafe?
Potentially. It's a good idea to NOT have port 81 flapping in the breeze
with those RaQ boxes.
The scary thing is how many of these boxes you can find with a few
well-crafted queries to altavista or alltheweb.com.
-joshua
---
======[S-D-G]==============================[-0.809016994]====
Joshua Ellis Dynamic Software, Inc. jel...@dsigb.com
Phone: 920/432-4454 ext.30 http://www.dsigb.com
Kurt Seifried
> 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.
Wouldn't it be a LOT more secure if the webserver ran as nobody and the
scripts that needed to run as root, well ran as root (and had properly
paranoid input checking). What you are saying is correct, but it is obvious
that Cobalt took the easy way out on this one and either needs to do quite a
bit of work to fix it, or can leave the status quo, at which point it
becomes inevitable that someone will find a flaw that they can exploit and
boom, every RaQ 3 now has an extra root account or five. Letting vendors get
away with this kind of stuff is exactly why we're in such a mess.
> Thanks and best regards,
> Francis
-Kurt
Brian Behlendorf
> 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
Wichert Akkerman
> Wouldn't it be a LOT more secure if the webserver ran as nobody and the
> scripts that needed to run as root, well ran as root (and had properly
> paranoid input checking).
One could use userv here to interact with the tools that need to be root,
that should improve things majorly.
Description: `user services' - program call across trust boundaries
userv allows one program to invoke another when only limited trust
exists between them. It is a tool which can be used to avoid having
to give other system services root privilege, and which allows users
to more securely have programs provide services to others.
Wichert.
--
_________________________________________________________________
/ Generally uninteresting signature - ignore at your convenience \
| wic...@wiggy.net http://www.liacs.nl/~wichert/ |
| 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Peter W
> > 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.
> Wouldn't it be a LOT more secure if the webserver ran as nobody and the
> scripts that needed to run as root, well ran as root (and had properly
> paranoid input checking). What you are saying is correct, but it is obvious
> that Cobalt took the easy way out on this one and either needs to do quite a
> bit of work to fix it, or can leave the status quo, at which point it
> becomes inevitable that someone will find a flaw that they can exploit and
> boom, every RaQ 3 now has an extra root account or five.
Kurt,
I don't think that's so clear cut. I use Netscape's Enterprise web server.
Its admin httpd runs as root -- when I have it running, that is. At other
times, it's just a plain old Unix app doing nothing. Harmless. Impotent.
You think having SUID binaries lying around on the filesystem is a better
idea? Runnable by --you said it-- 'nobody'?[0] Maybe even run by random
other local users? So other minor exploits (including exploits in weak CGI
apps installed in other, non-admin, run-as-nobody httpds) or unprivileged
local access could be used to run/abuse the always-available SUID apps?
Sure, you could tighten it a bit more by running the admin httpd as
"w3raqadm/w3raqadm" or something, with mode 4550 root:w3raqadm CGI apps,
etc., but it's not obvious to me that an httpd running as root is
necessarily any more dangerous than one running as nobody with suid CGI
apps. Especially when the httpd[1] (Apache) has undergone much more
thorough scrutiny than the administrative apps.[2]
But in many cases a plain old binary like /bin/linuxconf that you can
stop/disable to render it harmless is safer than a suid binary that
presents continual local exploit potential. Certainly often enough to
debunk your blanket assertion that suid apps are "a LOT more secure".
Just because it looks like "the easy way out" doesn't mean it's wrong.
-Peter
[0] IMO, Web servers ought to have special uid's to better isolate them
from the rest of the system. 'nobody' is better than 'root' for normal
httpds, but is still not as safe/controlled as well done httpd-only
user/group configs. When possible, separate httpds should have individual
uid/group setings. No httpd should have write perms to any areas where
executable content can reside -- CGIs, servlets, even normal content if
you have something like PHP or CGI-by-extension enabled. It kills me to
see all these hosting companies that give each customer a single uid that
owns the doc root, the scriptalias dir, everything. What a nightmare.
[1] It does seem a good idea to have a separate installation of Apache for
admin use, compiled with a minimal set of modules, etc., so a user is less
likely to "upgrade" Apache with some third-party or homegrown C/Perl
module that puts the run-as-root admin httpd at greater risk. I have no
idea if that's the case with Cobalt, or what warnings they may have in
their documentation about modifying the admin httpd code.
[2] Conflicting principles here: On the one hand, the admin apps might be
much shorter & simpler than the Apache httpd code. Easier to audit. On the
other hand, the Apache httpd code has been reviewed by a lot more people;
the presence of safeguards like the BIG_SECURITY_HOLE definition
illustrates how seriously the Apache group takes its code. They care.
They're careful.
--
http://www.bastille-linux.org/ : working towards more secure Linux systems
Edward S. Marshall
> You think having SUID binaries lying around on the filesystem is a better
> idea? Runnable by --you said it-- 'nobody'?[0] Maybe even run by random
> other local users?
That particular trust issue is a solvable problem, especially in this
case.
Imagine a wrapper script for Apache which generates a random cookie and
writes it to a file readable only by root (and then executes Apache with
reduced priviledge, perhaps passing in file descriptors for the ports it
needs while doing so, ala INN's "startinnd").
Then imagine a setuid helper application (say, a modified suexec) whose
sole purpose in life is to read that cookie file, receive the cookie via
some form of IPC from Apache, compare the two, and allow execution of one
application within a specific set of permitted programs if the cookie
matches.
(No, this isn't a new idea; I believe the RTR Frontpage extensions do
something like this, if memory serves, although they do it within Apache,
instead of using a wrapper.)
--
Edward S. Marshall <emar...@logic.net> http://www.nyx.net/~emarshal/
-------------------------------------------------------------------------------
[ Felix qui potuit rerum cognoscere causas. ]
Forrest J. Cavalier III
of the idea mentioned by E Marshall is discussed at:
http://officeupdate.microsoft.com/frontpage/wpp/serk/scuni.htm
(And as a bonus for checking just now, they seem to have finally
published the FrontPage client-server RPC API too!)
http://msdn.microsoft.com/workshop/languages/fp/default.asp
Forrest J. Cavalier III, Mib Software
Get links to code and the knowledge to use it.
http://www.rocketaware.com/ Programmer's Webliography
"Edward S. Marshall" <emar...@LOGIC.NET> wrote, in part: