Strange tripwire behaviour
Aleksandar Milivojevic
amilivojevic at pbl.ca
Wed Mar 30 16:03:25 UTC 2005
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
More information about the fedora-list
mailing list