Red Hat Bugzilla – Bug 981918
Inexplicable differences between "identical" installations (security issue?)
Last modified: 2014-03-16 23:33:59 EDT
After rkhunter kept reporting weird changes to my system, I decided to do my best to investigate whether my system had been compromised.
I did this by installing a clean copy of the same version of Fedora on an encrypted partition, and putting the boot partition on a thumb drive that (since being repartitioned/reformatted) has only been connected to my machine while this "clean" installation was running, or when running rescue mode straight from the install DVD.
The "clean" system has only accessed the Internet through wget (to grab the rpmfusion release RPMs) and through package management (i.e. yum and fedup). I've never run a web browser on it, or X Windows for that matter; immediately after installation, I changed the default runlevel to multi-user (i.e. 3). I don't know how to be any more careful; if anyone has some advice, I'd like to hear it.
After making sure all the packages on my in-use system had been installed, I booted into the clean system, mounted the in-use system, and did a binary diff (i.e. "diff -raq") between the two, and found several inexplicable differences. The really weird thing is, both systems pass "rpm -V" on the affected packages.
There are more differences than these, but these include the scariest ones, e.g. java and sendmail. (The in-use system is mounted as "/dirtyroot".)
-rw-r--r--. 1 root root 681 Jun 27 20:51 /dirtyroot/usr/lib/gtk-3.0/3.0.0/immodules.cache
-rw-r--r--. 1 root root 672 Jul 5 22:37 /usr/lib/gtk-3.0/3.0.0/immodules.cache
I was also having a problem with /usr/lib/libnss_compat_ossl.so.0.0.0 (from the nss_compat_ossl package), but that went away with a "yum reinstall". Keep in mind that both installations passed "rpm -V".
It seems like there might be more than one version of these packages out in the yum-repo mirrors, but since they're all digitally signed with Fedora's private key, I don't see how this can be. Still...something very strange is going on, and I fear it's security-related.
I was having similar issues with F17, but since that just went end-of-life, I redid the investigation with F18, and found pretty much the same thing. java and sendmail come up consistently, and pkcs11-helper has shown up too, but isn't at the moment.
Finally, practically every .mod file in /boot/grub2/i386-pc came up different, though those apparently aren't associated with any package.
Any idea what could be behind these differences?
All of those seem to be files that are generated at rpm install time via scriptlets, and contain things like timestamps/dates.
Still, that doesn't explain the oddness with nss_compat_ossl and pkcs11-helper, does it? Or how practically every .mod file in /boot/grub2/i386-pc is different?
Also...is the process that I outlined for creating a clean system a sensible one? None of these comparisons have any meaning if it's just as compromised as my in-use system.
I guess I should have kept the first version of my possibly-compromised system, but at the time, I wasn't thinking about reporting the problem, just fixing it.
(In reply to Steve from comment #2)
> Still, that doesn't explain the oddness with nss_compat_ossl and
> pkcs11-helper, does it?
Yeah, those I think are a real prelink bug with it not unprelinking them correctly.
You could test by installing prelink, reinstall and prelink one of them, unprelink and see if it fails to verify.
>Or how practically every .mod file in
> /boot/grub2/i386-pc is different?
Those are generated at install time.
> Also...is the process that I outlined for creating a clean system a sensible
> one? None of these comparisons have any meaning if it's just as compromised
> as my in-use system.
I have no idea what threats you are trying to protect against, so I can't say if this is a good model to protect against them. This should be a good way to have a reference system sure.
I ran "prelink -ua; rpm -e prelink" on both my in-use and clean systems, so hopefully the problem will go away. I'll report back here if anything else strange happens.
Thanks for pointing out %ghost, i.e. files that get generated at install time and so would be different between otherwise identical installations.
I'm trying to detect if/when my system gets compromised in any way. I'm hoping to maintain my "clean" system by not using it for anything but installing/updating packages, so that I can compare it to my in-use system and detect any changes, e.g. if tripwire or "rpm -V" somehow get compromised.
Now that I'm running Firefox in an SELinux sandbox, without Adobe Flash, and with the noscript addon, hopefully I've closed off all possible attack vectors. I wish I could find more net.resources for this sort of thing. linux-sec.net looks decent, but has a LOT of information.
This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '18'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 18's end of life.
Thank you for reporting this issue and we are sorry that we may not be
able to fix it before Fedora 18 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior to Fedora 18's end of life.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
Thank you for reporting this bug and we are sorry it could not be fixed.