Strange tripwire behaviour

[Aleksandar Milivojevic]

Jeff Kinz wrote:

> Scott is correct on both counts, prelink is the likely culprit, but
> don't discard the idea of a very thorough intrusion effort.

If it was intrusion, and rootkit installed was that thorough to actually 
replace tripwire binary, than he probably wouldn't see the change in 
tripwire binary either.

Of course, being a bit paranoid never hurts.

BTW, a bit of topic.  Tripwire as tool for detecting RAM problems.  Some 
time ago, tripwire detected a change in single bit in one shell script. 
  Upon examining the file, one " character (double quote, hex code 0x22) 
was changed to "2" character (hex code 0x32).  But only when looking at 
the file through the file system.  Partition was mirrored, and checking 
the files directly from each of submirrors (simply mounted each 
submirror in read-only mode) showed unchanged file.  After running 
"memory intensive program" to clean the cache, voila, looking at the 
file at the file system showed original file.  Apperently, machine had 
enough RAM to cache all files checked by tripwire and keep them in cache 
for weeks (never read them from disk, other when machine is booted). 
Because of the bad RAM chip (verified, running memtest86 on that memory 
module for couple of weeks showed errors occuring after long periods of 
time), one bit flipped.  Had there not be tripwire, memory problem would 
be undetected (memory in question was not ECC).

So, giving extra $$$ for ECC memory and motherboards that support it 
isn't a bad idea after all...  Not all memory problems will make your 
machine crash.  You may be running bad memory module for months or years 
before realizing it.

I also have a similar story when tripwire detected problems with Linux 
RAID1.  One night tripwire would report one file changed, the other 
night reported it unchaged.  And it went on flipping for some time. 
What happened was that machine had crashed when that file was accessed, 
and mirrors went out of sync.  Upon booting, (an early version of) MD 
driver hasn't detected the problem and considered submirrors to be in 
clean state (ooops).  But tripwire did, since each night kernel randomly 
gave it a copy from either first or second submirror.  Tripwire as tool 
for detecting kernel bugs ;-)

Thinking of it, I don't recall reporting the bug.  Who knows, maybe it 
was never fixed 8-\

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7