Mailinglist Archive: opensuse-features (327 mails)
| < Previous | Next > |
[openFATE 306508] External checksum for supplied files
- From: fate_noreply@xxxxxxx
- Date: Thu, 22 Oct 2009 22:36:23 +0200 (CEST)
- Message-id: <feature-306508-10@xxxxxxxxxxxxxx>
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 #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
| < Previous | Next > |