Re: [cobalt-security] RE: The nasty RaQ hack...

[Eugene Crosser <crosser@xxxxxxxxxxx>]

On Thu, 2003-01-23 at 09:16, Mail List wrote:
> >First of all, according to the docs published for the hack, a quick fix
> >is to chmod 755 /usr/lib/authenticate if it's not already set to that.
> 
> But doesn't this cause some authentication problems, particular 
> FrontPage?  I thought I read previous discussions in the archives where 
> some people experienced authentication issues after changing permissions to 
> 755 shortly after the RaQFuCk.sh script first hit the wild.
> 
> I have my RaQ4 patched up to the point (but not including) Kernel Update 
> 2.0.1 C33 -and gcc set with:
> 
> -rwx------   2 root     root        74572 Apr  9  2002 gcc
> 
> But even patched, authenticate is still set with setuid:
> 
> -rwsr-xr-x   1 root     root        18316 Aug  6 14:16 authenticate
> 
> If removing the setuid on authenticate wouldn't mess with things, why in 
> the world would Cobalt leave it set when they -supposedly- patched the 
> RaQ4's against this authenticate issue previously? I'm just trying to 
> understand why if setuid weren't needed, would they leave it set on a file 
> (call me stupid)?
> 
> Just trying to make sense out of this without mucking with things that 
> might not need mucking with if already secure (but that's the real question 
> here isn't it)..?  There do seem to be a slight increase in recent hacks on 
> RaQ's -I'm guessing because they weren't fully patched and/or no firewall 
> and/or lack of other security measures.  Just curious..

Before a recent update, /usr/lib/authenticate had a bug that, together
with the fact the the program is setuid, could be exploited to gain root
access.  By un-suid-ing the program you could prevent exploit at the
cost of authentication problems.  After the update, you have this
program with the bug fixed, so that it cannot be exploited, and it is
setuid, so it can do the authentication job properly.  (Do I sound
comprehensible?)

Eugene