From Bugzilla Helper: User-Agent: Opera/8.52 (X11; Linux i686; U; en) Description of problem: Hmm - rkhunter and chkrootkit say everything is clean, but most, not all, libraries and _binary_ files larger than about 4096 bytes have a larger file size, and different file contents, compared to files from the corresponding rpm package. For the "larger" files, 'strings /usr/bin/<somefile>' always gives a line '/Cx2' near the top of the output, and a repeated line '/lib/ld-linux.so.2' near the bottom of the output from 'strings', compared to the same file from the rpm package. Also, the output from 'strings' from the larger files looks vaguely like upper half and lower half hunks are swapped, top to bottom, compared to the output for the same file from the rpm package. Question: Is this something to do with the ext3 filesystem, or with the way rpm writes files to disk? Or has this box maybe been rooted? by some rootkit nobody knows anything about? Version-Release number of selected component (if applicable): rkhunter-1.1.9-1 How reproducible: Always Steps to Reproduce: 1.sudo rkhunter --checkall --rootdir <nfs-mounted other machine> 2.ls -l /usr/bin/<anything seemingly bigger than 4096 bytes> 3.rpm -vV <whatever> Actual Results: For 1 - says everything is clean For 2 - gives a file size larger than what comes out of the rpm package. For 3 - usually says everything is fine, but did notice that "/usr/bin/passwd" had the wrong size, unless rpm - a version of rpm clean from the rpm package - was run as root, in which case, rpm did not notice the size difference. Expected Results: One might expect rkhunter to notice that the file sizes are all too large? Or rpm should notice? Or the rpm database has been buggered? Additional info:
*** Bug 183070 has been marked as a duplicate of this bug. ***
*** Bug 183071 has been marked as a duplicate of this bug. ***
*** Bug 183072 has been marked as a duplicate of this bug. ***
*** Bug 183073 has been marked as a duplicate of this bug. ***
this is most likely an issue with prelink. to verify run prelink -ua and then double check what they show then. from man prelink prelink is a program which modifies ELF shared libraries and ELF dynamically linked binaries, so that the time which dynamic linker needs for their relocation at startup significantly decreases and also due to fewer relocations the run-time memory consumption decreases too (especially number of unshareable pages). Such prelinking information is only used if all its dependant libraries have not changed since prelinking, otherwise programs are relocated normally. prelink first collects ELF binaries which should be prelinked and all the ELF shared libraries they depend on. Then it assigns a unique virtual address space slot for each library and relinks the shared library to that base address. When the dynamic linker attempts to load such a library, unless that virtual address space slot is already occupied, it will map it into the given slot. After this is done, prelink with the help of dynamic linker resolves all relocations in the binary or library against its dependant libraries and stores the relocations into the ELF object. It also stores a list of all dependant libraries together with their checksums into the binary or library. For binaries, it also computes a list of conflicts (relocations which resolve differently in the binaryâs symbol search scope than in the smaller search scope in which the dependant library was resolved) and stores it into a special ELF section. At runtime, the dynamic linker first checks whether all dependant libraries were successfully mapped into their designated address space slots and whether they have not changed since the prelinking was done. If all checks are successful, the dynamic linker just replays the list of conflicts (which is usually significantly shorter than total number of relocations) instead of relocating each library.
Sorry about the duplicates. Opera and Bugzilla do not play nicely together. It was running on automatic before I stopped it. > this is most likely an issue with prelink. to verify run prelink -ua Yes, that seems to solve the mystery. Live and learn... and no root kit. Thanks. BTW, do you think "rpm -V" should say something about the "prelink" change to the files? It seems odd otherwise.
"rpm -V" is aware of prelinking.
Reading from the rpm man page, there is no mention of "prelink", or that a file size has been changed by prelink: The format of the output is a string of 8 characters, a possible attribute marker: c %config configuration file. d %doc documentation file. g %ghost file (i.e. the file contents are not included in the package payload). l %license license file. r %readme readme file. Otherwise, the (mnemonically emBoldened) character denotes failure of the corresponding --verify test: S file Size differs M Mode differs (includes permissions and file type) 5 MD5 sum differs D Device major/minor number mismatch L readLink(2) path mismatch U User ownership differs G Group ownership differs T mTime differs The rpm -V command could be enhanced with an additional "attribute marker": p %prelink this file has been modified by prelink. The file size and md5 sum may differ from the original file.