rkhunter, clarify couple points

skola · 03-20-2012, 10:10 AM

I'd like to have a couple of points clarified please, wrt the FAQ file.

Code:

Usage 3.A.5  
Run 'file <file>' and compare...trusted binaries. If some binaries are statically linked and others are all dynamic, then they could have been trojaned.

Q. Does the "they" above refer to the _statically_ ?

doing a 'file' on all the bin directories shows majority are dynamic and 6 with '*.static' names and 5 single word names as statically. From both a fresh and established install.

Usage 3.8.A

Code:

Your system probably uses prelinking (the log file will say if
it does or not). Sometimes a file may be updated but not be
prelinked. When this happens RKH cannot determine the files hash
value. If you run the command 'prelink --verify --sha <file>'
on the file, it will probably give an error about the files
dependencies having changed. This is what RKH sees, and flags
it as a missing hash. If you are sure that the file is genuine,
then you can try using 'prelink <file>' to correct it. The
'prelink' command above should then work. Re-run RKH with the
'--propupd' option to ensure that all the hash values are recorded.

and

Errors Warnings 4.4.Notes

Code:

1) If the logfile indicates that a files' hash value has changed
from some value to 'No hash value found', and your system
uses prelinking, then the file probably needs to be
specifically prelinked. This can usually be done by running
the 'prelink' command on the relevant file. Running RKH with
the '--propupd' option afterwards will indicate if there
are still any hash values missing. Check the logfile and
repeat the above process of prelinking the files.

RKH will try and determine if your system is using prelinking
or not. The logfile will contain the result of the check.

Q. Does the RKH database, via propupd, take account of both the actual ELF file's own attributes _and_ its dependencies, meaning that if _either_ of those are changed then a warning is issued?

The second question is my main reason for the post.

I keep 2 partitions for my distro, one being a smaller maintenance part and both kept uptodate. I did an update on the main with the package manager and afterwards ran RKH. I got a dozen warnings for some bins including - rpm,insmod,depmod,lsmod,modprobe,rmmmod,wget,curl

the warnings being - No hash value, file size, time, changed.

This is the point. Rebooting to a Live CD and looking at both main and maintenance partitions, those ELF files are exactly the same, size and date, plus using 'cmp' on them gives no changes.

Also the updates had nothing to do with them _directly_. Looking at the RPMs I saw nothing to link, either in the update files or any script that might be run as part of a particular RPM.

The system does use 'prelinking', and there's another sentence in the RKH FAQ about 'Libsafe' but that is not installed.

I'm sure I have only seen a 'bins' warning when an update _directly_ involved the particular file and doing a propupd sorted it.

So, having restored a backup prior to that update, my main question is: Does RKH record library dependencies in addition to an ELF binary's own attributes, and it would give a warning about the file even if any obscure library is changed?

unSpawn · 03-20-2012, 12:02 PM

Quote:

Originally Posted by skola

I'd like to have a couple of points clarified please, wrt the FAQ file.

Ah. Somebody who actually reads documentation ;-p

Quote:

Originally Posted by skola

Does the "they" above refer to the _statically_ ?

Yes, it does. Linking in dependencies making binaries self-contained was a way to ensure they could be deployed more easily. These days however it's not that common anymore to see system binaries be introduced.

Quote:

Originally Posted by skola

Does the RKH database, via propupd, take account of both the actual ELF file's own attributes _and_ its dependencies, meaning that if _either_ of those are changed then a warning is issued?

No. RKH doesn't track attributes of dependencies but you are free to add any file to the check.

Quote:

Originally Posted by skola

I keep 2 partitions for my distro, one being a smaller maintenance part and both kept uptodate. I did an update on the main with the package manager and afterwards ran RKH. I got a dozen warnings for some bins including - rpm,insmod,depmod,lsmod,modprobe,rmmmod,wget,curl the warnings being - No hash value, file size, time, changed. This is the point. Rebooting to a Live CD and looking at both main and maintenance partitions, those ELF files are exactly the same, size and date, plus using 'cmp' on them gives no changes. Also the updates had nothing to do with them _directly_. Looking at the RPMs I saw nothing to link, either in the update files or any script that might be run as part of a particular RPM. The system does use 'prelinking', and there's another sentence in the RKH FAQ about 'Libsafe' but that is not installed. I'm sure I have only seen a 'bins' warning when an update _directly_ involved the particular file and doing a propupd sorted it. So, having restored a backup prior to that update, my main question is: Does RKH record library dependencies in addition to an ELF binary's own attributes, and it would give a warning about the file even if any obscure library is changed?

If you inspect the RKHDB you see the only attributes recorded are the items path and file name, hash, inode, access perms and ownership, size and modification time. A benign process like prelinking might change the inode, for writing the file to new location, and if any values change compared to those stored in the RKHDB you get an alert. Posting a few entries from your rkhunter.log could help as I like reporting or data more than a description of a problem. What does not help is restoring a file systems contents and then report a potential problem as that successfully blocks troubleshooting (or meaningful investigation, were this an actual security incident).