[15903] in bugtraq
Re: Cobalt RaQ 3 security hole?
daemon@ATHENA.MIT.EDU (Kurt Seifried)
Fri Jul 21 20:12:54 2000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <023501bff34e$f73afca0$6900030a@seifried.org>
Date: Fri, 21 Jul 2000 14:05:06 -0600
Reply-To: Kurt Seifried <listuser@seifried.org>
From: Kurt Seifried <listuser@seifried.org>
X-To: "Francis [loaded.net]" <francis@BEST.COM>
To: BUGTRAQ@SECURITYFOCUS.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.
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
