Re: Cobalt RaQ 3 security hole?

[peterw () USA NET (Peter W)]

At 2:05pm Jul 21, 2000, Kurt Seifried wrote:

> > 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