Feature changed by: Bernhard Wiedemann (bmwiedemann) Feature #306508, revision 10 Title: External checksum for supplied files openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Elmar Stellnberger (estellnb) Requested by: Marcus Meissner (msmeissn) Description: (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 (https://bugzilla.novell.com/show_bug.cgi?id=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. Relations: - provide boot cd to md5sum core system files (novell/bugzilla/id: 491193) https://bugzilla.novell.com/show_bug.cgi?id=491193 Discussion: #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 useless. #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 #2) 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> + #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. -- openSUSE Feature: https://features.opensuse.org/306508