Home_greyopenFATE - openSUSE feature tracking > #306508
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

External checksum for supplied files

Feature state

Rejected Information


(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.



icons/user_comment.png E. S. wrote: (9 years ago)

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 useless.

icons/user_comment.png A. J. wrote: (9 years ago)

Is this something that would really help in the mentioned use case? Do we have other solutions?

icons/user_comment.png E. S. wrote: (9 years ago)

Disposing over a checksum list of all known files is a very effective method to 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 http://www.elstel.com/checkroot . 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.<br>

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.<br>

icons/user_comment.png B. W. wrote: (8 years ago)

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.

icons/user_comment.png E. S. wrote: (8 years ago)

No,no,no. Please do carefully read the information at http://www.elstel.com/checkroot .

  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 stolen.

 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 checkroot.

icons/user_comment.png M. M. wrote: (8 years ago)

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 check.

icons/user_comment.png E. S. wrote: (8 years ago)

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 (
http://www.elstel.com/checkroot ).

icons/user_comment.png R. D. wrote: (8 years ago)

I used a package by Gene Spafford called trip wire under SunOS in the 90's.  I cannot believe there are not many mature intrustion detection packages, using multiple checksum formats (tripwire supported CRC32, MD4, SHA & others)  The idea is sound, the checksum database should be stored on RO medium, such as CD-ROM, or write flash memory card and does indeed work (at some inconvenience) in practice, though the fatal problem is that routines must be worked out before use.

For most oS & SLED/SLES users I would think, that providing an integrity check as a repair option against download.opensuse.org could detect corrupted files and suggest packages to re-install.

This is not going to suffice as it stands as an intrusion detection suite, because added files are not detected.  One of my uses for tripwire, was pre- & post- install of Sun software, as they began to inflict GUI installers on sysadmin's, which made their package installation painful and network unworthy, distributing the files and scripting config changes was made much more difficult..  With tripwire it was very simple to see what files were added, changed & removed.

icons/user_comment.png E. S. wrote: (8 years ago)

  A ro-checksum medium will be of no use as soon as you perform the first updates. The novelty about checkroot is the online package verification feature. As far as I have found it out tripwire just does an extended file change monitoring but no package verification - also useful but actually not what we have desired here.

spot added files, provide a repair feature: That would be interesting features for checkroot which I have already considered. However I have recently not had the resources to further work on checkroot. Some changes in drawing online checksums need to done. Support from the openSUSE community is a pitiely still lacking (keep old package headers online).

Last change: 2 years ago
Score: 10
  • Negative: 0
  • Neutral: 1
  • Positive: 10
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint