I'm new to this list, so feel free to update me on any rules that I seem not to be familiar with.
I'm looking at some strange behavior on a _very_ barebones installation. I'd like to get some feedback on possible logical explanations.
* What I'm seeing: The md5sum of all of my binaries in /usr/bin and /usr/sbin are changing exactly one hour after installation of CentOS-4.3. The sizes of the files are increased, with minor changes visible at the beginning of the files, and a large chunk added to the end. Other files are also changing (under /usr/lib for example. Tripwire, if installed, goes *nuts*).
My first inclination is that this is a virus, but I have installed this OS on a non-networked machine from what I believe to be clean CDs.
* More information: I downloaded the x86_64 installation ISOs from wuarchive.wustl.edu. I checked md5sums and burned the ISO images to CD and then checked the md5sums again. I am assuming this to mean that the CDs are OK.
I then installed the "Minimal" package from these CDs onto a machine which was not connected to the network. I allowed the installer to reformat the partitions, and generally used default options wherever possible.
I then rebooted the machine, and checked the md5sum of an example program (/usr/sbin/lsof). I set up a script to log the md5sum of /usr/sbin/lsof every 1 minute and let it run overnight. Exactly 1 hour after the machine had come up, the md5sum of /usr/sbin/lsof was now changed and the binary no longer matched a copy I had made into root's home.
Virus checkers such as clamav and f-prot (with updated databases) are negative. These are launched from a Helix Incident Response LiveCD.
I have repeated this experiment dozens of times now with different options, settings, etc. Always with the same outcome. I find it hard to believe there is a virus on the CentOS-4.3 installation ISOs, but I'm having trouble coming up with other explanations.
For starters, what is the md5sum of *your* /usr/sbin/lsof (if you've installed x86_64)? Any ideas on what is going on here? I can perform pretty much any experiments you can think of on this machine.
Am I missing a way for a virus to survive a reformat of the hard drive?
Thanks in advance for any help, John Ziniti
John Ziniti wrote:
I'm new to this list, so feel free to update me on any rules that I seem not to be familiar with.
I'm looking at some strange behavior on a _very_ barebones installation. I'd like to get some feedback on possible logical explanations.
- What I'm seeing: The md5sum of all of my binaries in
/usr/bin and /usr/sbin are changing exactly one hour after installation of CentOS-4.3.
man prelink
William Hooper wrote:
John Ziniti wrote:
I'm looking at some strange behavior on a _very_ barebones installation. I'd like to get some feedback on possible logical explanations.
- What I'm seeing: The md5sum of all of my binaries in
/usr/bin and /usr/sbin are changing exactly one hour after installation of CentOS-4.3.
man prelink
Aha! Well, the good news is that you are, of course, right and there is a logical explanation for this after all (Whew!).
The only bad news I guess, is that I've wasted so much time looking for a mysterious problem that isn't there :-/
Just for posterity, the following was what I used to verify that the changes were from prelinking:
# prelink --undo /usr/sbin/lsof # md5sum /usr/sbin/lsof
The md5sum from that last command gave me the result I desired. Re-running prelink on /usr/sbin/lsof gives me the "foreign" md5sum again. I guess I'll just have to prelink from now on before I initialize tripwire.
Thanks a ton, William. If you're ever in Boston, I owe you a [ affordable beverage of your choice ].
- JZ
John Ziniti wrote: [snip]
The md5sum from that last command gave me the result I desired. Re-running prelink on /usr/sbin/lsof gives me the "foreign" md5sum again. I guess I'll just have to prelink from now on before I initialize tripwire.
Just be aware that updating any of the shared libraries will cause a large number of binaries to change as they are re-prelinked. It might be worth turning prelinking off if tripwire is a major part of your security strategy.
On Wednesday 14 June 2006 19:40, John Ziniti wrote:
William Hooper wrote:
John Ziniti wrote:
I'm looking at some strange behavior on a _very_ barebones installation. I'd like to get some feedback on possible logical explanations.
- What I'm seeing: The md5sum of all of my binaries in
/usr/bin and /usr/sbin are changing exactly one hour after installation of CentOS-4.3.
man prelink
Aha! Well, the good news is that you are, of course, right and there is a logical explanation for this after all (Whew!).
The only bad news I guess, is that I've wasted so much time looking for a mysterious problem that isn't there :-/
Just for posterity, the following was what I used to verify that the changes were from prelinking:
# prelink --undo /usr/sbin/lsof # md5sum /usr/sbin/lsof
Maybe not quite helpful for setting up tripwire, but rpm -V can verify checksums on files (or more correctly on files belonging to rpm packages) even with prelink enabled.
Alternatively, if you havn't found it yet, prelink is disabled in /etc/sysconfig/prelink.
/Peter
The md5sum from that last command gave me the result I desired. Re-running prelink on /usr/sbin/lsof gives me the "foreign" md5sum again. I guess I'll just have to prelink from now on before I initialize tripwire.
Thanks a ton, William. If you're ever in Boston, I owe you a [ affordable beverage of your choice ].
- JZ
-
John Ziniti -
Peter Kjellström -
William Hooper