Feature changed by: Marcus Meissner (msmeissn) Feature #306508, revision 2 Title: external checksum for supplied files openSUSE-11.2: New Priority Requester: Desirable + Requested by: Elmar Stellnberger ATK (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 cheksum list could be implemented in the build service (see also: 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 -- openSUSE Feature: https://features.opensuse.org/306508

Feature changed by: Elmar Stellnberger ATK (estellnb) Feature #306508, revision 6 Title: External checksum for supplied files openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Elmar Stellnberger ATK (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 cheksum list could be implemented in the build service (see also: 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. -- openSUSE Feature: https://features.opensuse.org/306508

Feature changed by: Elmar Stellnberger ATK (estellnb) Feature #306508, revision 8 Title: External checksum for supplied files openSUSE-11.2: Evaluation Priority Requester: Desirable Requested by: Elmar Stellnberger ATK (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 cheksum 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> +   -- openSUSE Feature: https://features.opensuse.org/306508

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

Feature changed by: Michal Marek (michal-m) Feature #306508, revision 12 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. #5: Elmar Stellnberger (estellnb) (2009-10-27 19:06:29) (reply to #4) 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. + #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 + check. -- openSUSE Feature: https://features.opensuse.org/306508

Feature changed by: Robert Davies (robopensuse) Feature #306508, revision 14 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. #5: Elmar Stellnberger (estellnb) (2009-10-27 19:06:29) (reply to #4) 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. #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 check. #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 ( http://www.elstel.com/checkroot (http://www.elstel.com/checkroot) ). + #8: Robert Davies (robopensuse) (2009-11-30 23:12:50) + 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. -- openSUSE Feature: https://features.opensuse.org/306508

Feature changed by: Andreas Jaeger (a_jaeger) Feature #306508, revision 18 Title: External checksum for supplied files - openSUSE-11.2: Evaluation + openSUSE-11.2: Rejected by Andreas Jaeger (a_jaeger) + reject date: 2010-11-15 10:53:52 + reject reason: Not done in time for openSUSE 11.2 Priority Requester: Desirable Info Provider: (Novell) 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. #5: Elmar Stellnberger (estellnb) (2009-10-27 19:06:29) (reply to #4) 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. #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 check. #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 ( http://www.elstel.com/checkroot (http://www.elstel.com/checkroot) ). #8: Robert Davies (robopensuse) (2009-11-30 23:12:50) 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. #9: Elmar Stellnberger (estellnb) (2010-01-02 21:51:06) (reply to #8)   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). -- openSUSE Feature: https://features.opensuse.org/306508