On Thu, 17 May 2007, Keith Lofstrom wrote:

> I run ancient old tripwire nightly on my machines.  Yesterday, on my
> SL4.4 laptop, I noticed that it had found changes to  "vipw" and other
> security related tools.  A little concerned, I downloaded the latest
> version of chkrootkit and ran it, finding no problems.  I looked at
> the yum logs, and found a yum upgrade of util-linux from sl-errata;
> the header file shows that vipw and the rest had been updated.

Note also that by default various programs and libraries will have their 
contents changed periodically by the prelink stuff, and unless your 
tripwire knows to check the files after undoing the prelink-changes it 
won't get the right answers...

> False alarm, I am probably safe, assuming no outbreak of evil at SL or
> TUV (=The Upstream Vendor in North Carolina, for those wondering).
>
> I will react similarly if I ever see a change of the basic security
> programs.  Is there anything else a prudent administrator should check
> when these programs change?

Probably not.

We have some 'horrid' code which before/after package updates checks the 
checksums of files to be updated and updates our own local tripwire-like 
database accordingly.

I say horrid because if there are changes it didn't expect it just throws 
up it's hands in horror and mails the changes to us, we then also get the 
errors listed by the routine checking code and so it can be somewhat 
verbose.  It also can *only* work because it is part of the 
(ancient/horrible/evil) scripts we had for applying updates so it gets to 
intercept the list of packages to be upgraded before and after the 
update...

I suspect that with yum one needs to use the plugin interface to get 
similar levels of access, though one could probably fake it by parsing the 
output of 'yum check-update' and 'yum update' despite what the authors 
say...

Of course if you don't have your own checksum database you can just use 
rpm -V to check the files match those that rpm believes should be there 
(it knows to undo the prelink changes).  Of course that won't cope with 
files which are not part of any package (e.g. manually installed or made 
by magic in rpm install scripts etc).

Keeping a set of checksums local to the machine is only a benefit if 
attackers don't know to 'fix' that too, unless you can have it read-only 
or really make it immutable -- in which case you have problems updating it 
too :-)

In the last ~15 years while we have been running with our extra 'local' 
checks it hasn't once found a genuine attack/exploit -- though they do 
cause mild panics from time to time.

The rootkits are too good for that, they patch the kernel so the files 
seem to have the right contents/sizes/permissions etc after they have done 
their evil work...

I'm basing this on the last compromised system we found ~4 years ago, 
goodness only knows how clever they are now, but we havn't found them so 
they must be too clever for me... :-(

  -- Jon