Could RedHat scheduled update go wrong?

[Andrew Teal <A Teal hud ac uk>]

Hello, following on from previous conversations (thanks for response).

I managed to boot and start/enable one or two services by re-referencing
(deleting and re-creating) some of these self-referencing links.

lsattr then gave ------------------- (approx) -- does that mean no
attributes ? -- for all files except the self-referencing links, which of
course it rejected out of hand.

I looked at /var/logs/messages and found evidence only of people *trying*
ftp, all rejected. Shortly after I scheduled RedHat updates, a call to sshd
succeeded, followed by atd and lpd being shutdown and started up (twice) --
is that normal, or the trace of the hacker? The timings match the creation
dates of all these odd files and (if the files are indeed RedHat's traces)
indicate the former. 

OK, so I don't *think* I've been hacked by anyone other than RedHat :-) --
but I have to admit I believe these odd symlinks started showing up before I
tried the scheduled update. Not before using RPM/RHN, though (I think).
[Note: keep a diary next time :) ] What other symptoms are likely to help me
decide?

Minimal services are/were allowed in /etc/hosts.allow -- in fact I just
restricted everything to my desktop machine (I control the recalcitrant over
the network). I naively (?) thought this would exclude any hacking attempt.
I half expected the scheduled update to fail altogether and was slightly
surprised it reported success. 

I'm now in the position that I've messed around so much that the OS is not
accessible (fsck having 'over-corrected', I guess), so any more info
will/may come from an emergency boot. Current plan is to go for a fresh
install of 8.0, but my worry is leaving open any vulnerability that may have
been exploited.

I intend to study and follow any advice in
http://www.redhat.com/docs/manuals/linux/RHL-8.0-Manual/security-guide/; but
how sure can I be that the Redhat Scheduled update was not the cause of the
problem? Do I dare to use it in the future?

Grateful for any comments.

-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
 Andrew Teal  Information Techologist
 School of Human & Health Sciences
 University of Huddersfield, 
 Queensgate, Huddersfield, HD1 3DH
<a teal hud ac uk>  Tel: 01484 473674
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-




> -----Original Message-----
> From: Gordon Messmer [mailto:yinyang eburg com]
> Sent: Thursday, October 17, 2002 10:43 PM
> To: enigma-list redhat com
> Cc: Wylug-help (E-mail)
> Subject: Re: vicious circular symlinks stop su (and a lot more)
> 
> 
> On Thu, 2002-10-17 at 04:54, Andrew Teal wrote:
> > The critical error is
> > su: error while loading shared libraries: libpam.so.0: 
> cannot open shared
> > object file: Error 40
> > I've found that /lib/libpam.so.0 is a symbolic link to 
> itself; I can't
> > delete it because I can't su to root.
> 
> That all makes sense.  errno 40 == ELOOP (too many symlinks)
> 
> > AFAIK RedHat update created it. It also created (in the 
> same directory) four
> > versions of libpam.so.0.75 ** and four more 
> self-referencing symlinks:
> > libpam.so;3da73808 --> /lib/libpam.so;3da73808
> 
> OK, you've probably been hacked.  The filenames you've listed are temp
> names created when RPM unpacks an archive.  Normally, those files will
> be renamed to the destination file after they're complete.  However,
> renaming can fail for many reasons; among them is that the destination
> file has been made immutable.  Use "lsattr /lib/libpam*" to see if any
> of those files have been made immutable.
> 
> If so, and you didn't make them immutable yourself, then your machine
> was probably hacked.  Back up your data, reformat the disk, reinstall
> the OS.
> 
> 
> 
> 
> _______________________________________________
> enigma-list mailing list
> enigma-list redhat com
> https://listman.redhat.com/mailman/listinfo/enigma-list
>