[15897] in bugtraq
Re: Cobalt RaQ 3 security hole?
daemon@ATHENA.MIT.EDU (Joshua Ellis)
Fri Jul 21 17:47:31 2000
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <003a01bff290$e4465450$9914a8c0@sawing.com>
Date: Thu, 20 Jul 2000 16:24:27 -0500
Reply-To: jellis@dsigb.com
From: Joshua Ellis <jellis@DSIGB.COM>
X-To: Chad Day <cday@BEACHASSOCIATES.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <A8D9B16D2196D2118B6E00A0C9E307F4238680@beachpdc1.beachassociates.com>
> 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 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. jellis@dsigb.com
Phone: 920/432-4454 ext.30 http://www.dsigb.com
