Mailinglist Archive: opensuse-features (328 mails)

< Previous Next >
[openFATE 306508] External checksum for supplied files
  • From: fate_noreply@xxxxxxx
  • Date: Sat, 31 Oct 2009 15:07:11 +0100 (CET)
  • Message-id: <feature-306508-13@xxxxxxxxxxxxxx>
Feature changed by: Elmar Stellnberger (estellnb)
Feature #306508, revision 13
Title: External checksum for supplied files

openSUSE-11.2: Evaluation
Requester: Desirable

Requested by: Elmar Stellnberger (estellnb)
Requested by: Marcus Meissner (msmeissn)

(on behalf of Elmar Stellnberger)
I would appreciate the openSUSE-project to keep sha-1s/md5sums of all
valid files as other professional OS vendors do (Microsoft, Apple). I
believe the effort to implement this would not be too high; the
creation of an automatic checksum list could be implemented in the
build service (see also: Bug 491193
( ).
To me keeping such a list is the only way to verify that a system is
clean because in my case attackers succeeded to alter the checksum
table of the rpm database (rootkit was additionally not found by any
antivirus sw i.e. clamav, norton, chkrootkit, etc.).
Without such a checksum table I had to recreate a plain installation by
hand (i.e. some self written script) by redownloading exactly the same
realease and package versions from the same source as they had been
drawn originally from in order to compare both roots: very cumbersome,
laborious (about 2000 packages) and error prone; some packages from
Packman differed although they were of same version, release and
download URL; others were not available any more.
I believe maintaining such a checksum table would be a true win for the
openSUSE project in means of security and error reporting.

- provide boot cd to md5sum core system files (novell/bugzilla/id:

#1: Elmar Stellnberger ATK (estellnb) (2009-07-27 10:51:12)
Tools like Aide and Samhain are no alternative for this since they alas
(erst) store md5sums locally. Locally stored md5sums can be
manipulated. Besides this checksums external to the package management
will report changes on updates which deems the whole mechanism pretty

#2: Andreas Jaeger (a_jaeger) (2009-08-11 15:32:58)
Is this something that would really help in the mentioned use case? Do
we have other solutions?

#3: Elmar Stellnberger ATK (estellnb) (2009-08-12 12:24:39) (reply to
Disposing over a checksum list of all known files is a very effective method
spot alterations in the root filesystems; at least if this list is
comprehensive (It can not reveal an intrusion merely affecting the home
data area, but this is just a completely different task).<br>
Using checksum lists poses a major advantage to the use of antivirus
and rootkit-finder software since it opens up a way to spot yet unknown
or undiscovered malware (there does not seem to be much research into
spotting Linux specific malware).<br>
While providing bare checksum lists is the most straight forward and
robust way to veryify a root-fs it certainly suffers from a major
drawback: Such lists can become very large, need a long time to be
fully downloaded and are thus unpractical for regular system checks as
these should take place. Yet such lists can comprise proprietary
software not organized in rpm-packages as well as known files at
different locations (/usr/local).<br>
The other approach is to verify checksums based on the md5sums stored
in rpm headers. A sample implementation of such a tool can be found at The major advantage is that only the
checksums of installed packages have to be downloaded, if at all (this
only if the signature of the locally installed package header can not
be verified against a freshly downloaded superkey).<br>
So far so good. The rpm based approach suffers from certain drawbacks
as well.<br>
First and most important such a tool can not do without additional
investments into the security infrastructure as well.<br>
Currently the most important problem to checkroot is that you need a
fully updated system in order the verification process to succeed. It
happens very often that a package header is not any more available in
the installed version-release flavour. This sounds much easier than it
really is since sometimes the newest version will not be installed due
to dependency conflicts or because no .patch/.delta rpm is available
for upgrade. Despite of an own --update facility and various
improvements checkroot still does not accomplish a 100% package
coverage at verification.<br>
To my mind the only solution to this problem would be to keep headers
of old packages online - for factory repos as well as external repos
like packman. This will also be required in case of applying the tool
to a system that is known to be cracked - you must not destroy the
traces of an intrusion by updating! If there should be interest in this
alternative approach I will modify Michael Schroeders mkpristine to
create .header.rpm-s out of full rpms to keep the .header.rpms online.
A second possible drawback is that such an rpm --verify based tool is
much more complex than a bare md5sum list and thus more error prone. I
have seen rpm --verify to fail on manipulated packages and return 0 as
if everything was ok. Other errors may hide in a complex tool like this.

#4: Bernhard Wiedemann (bmwiedemann) (2009-10-22 22:35:57)
try   rpm -qa --verify
to find all files that belong to some package and are modified. This
would of course miss things that attackers place in the typical conf.d
dirs like /etc/cron.d/ . But most checksumming tools ignore that.
There are more ways to subtly alter an installation by attackers that
may never be spotted with hash based checks. e.g. modifying /root/.
ssh/authorized_keys or editing other configs to be unsafe.
Of course, with kernel-root-kits being around for a decade, you need to
boot off a clean medium (liveCD/netboot), because otherwise
modifications can be cloaked / hidden from you.

#5: Elmar Stellnberger (estellnb) (2009-10-27 19:06:29) (reply to #4)
No,no,no. Please do carefully read the information at
  Checkroot has been designed to overcome several security holes of rpm
--verify. First rpm --verify has no alternative strategy if the header
signature verification fails which happens for several packages even on
a clean new install. Even worse it does not even report that. Then it
does no online refetch of the keys. Attackers can simply place their
own key to sign packages which renders an rpm --verify --root
absolutely useless in means of spotting attacks. Third even keys can be
 The reason why I have invented checkroot was that my computer was
compromised, but rpm --verify --root from a clean verified boot CD did
not show any changes which could however quickly be spotted by

#6: Michal Marek (michal-m) (2009-10-29 14:51:29)
What about generated files, like the initrd? What about config
directories where each file is automatically picked up, like
/etc/profile.d or /etc/modprobe.d?Just checking against a list of
checksums won't make you secure. Also the checksums (md5s) are in the
rpm headers already, presenting the checksums in a standalone file in
the repository metadata would be nice, but there are lot more things to

+ #7: Elmar Stellnberger (estellnb) (2009-10-31 15:06:17) (reply to #6)
+ Yes, certainly. However I am not yet sure whether rpm --verify does
+ already perform some checks of this kind. If so my checkroot tool that
+ is based upon rpm --verify would be rather comprehensive. I believe
+ these tests should be included in rpm --verify. Anyway this is a point
+ that argues for automatic verification tools like checkroot (
+ ( ).

openSUSE Feature:

< Previous Next >
This Thread