[Manoj, I'm going to concentrate on this example, it's probably a corner
case and I'm probably digressing here ... oh well....]
On Thu, Dec 04, 2003 at 11:17:46AM -0600, Manoj Srivastava wrote:
> > Finally, there's one thing md5sums in packages can provide that no
> > other solution proposed in this thread can: a database of known good
> > signatures [1].
>
> Uhhh -- if this were indeed important, it is easy to generate
> such a list from a known good set of .debs. Why exactly is
> publishing such a list usefule, and not mere make work?
Why do we have to make each of our users find a solution to generate this
from a _local_ mirror (or the system's .deb archive which shoulnd't be
trusted in the event of an intrusion) when we could do this ourselves and
provide the results?
It is not that much work and known good databases are really useful in
forensic investigation (see below or read Sleuth Kit informer issue #6,
http://www.sleuthkit.org/informer/sleuthkit-informer-6.html)
>
> > Many vendors [2] provide a full list of valid md5sums for their
> > operating systems which enables investigators to determine if a file
> > belongs to the system or it has been modified.
>
> If you want a list of such files, we have it now. If you want
We have the information, but it needs to be extracted. Not all users/admins
now how to handle our archive, and there are no standard tools to do what
I'm askin for (again, see below)
> to do a security audit, the md5sum is useless. An integrity check
No it's not, see below.
> could perhaps use this, and most systems would be better off with
> DPkg::Post-Invoke {
> "debsums --generate=nocheck -sp /var/cache/apt/archives";
> };
If I want to do a security audit of a compromised system, taken offline, of
which I have a hard disk image, md5sums are _not_ useless. If I have a list
of known good checksums (provided by the vendor) I can compare them with
the files and see what files might have been changed by an intruder. I can
also use them to detect what packages do files belong to and see if the
packages are known to have security holes (i.e. the 'downgrade' case).
Notice that I'm not necessarily depending on the local md5sums, I'm taking
a file provided by a vendor, in this case, Debian. Let's call it
Contents-xxx.md5sum.gz. This file is available for download from all
Debian mirrors, signed with the Release key and provides these three fields
for every file in a single Release:
filename md5sum package
I don't see any reason why we shouldn't provide this and there are some
situations in which it would be useful (see below). In order to do this
we could either:
1) run a task on the mirrors to generate it (extract the files from the
ars, calculate the md5sum, etc..) when we make a Release
or
2) take the information on the package's md5sums file and put it in a
single file.
Now, with (2), at the same time, you are giving the users a way to
check the filesystem locally, i.e. do integrity checking "online". This
has several benefits as already described, but even more in the forensic
situation.
>
> > This is very useful in a forensic investigation since it enables a
>
> Bullshit. In a forensic investigation you can't trust on disk
> md5sums; and if you need to download the packages to verify the
> md5sum, you have a better check for integrity:
> # ar p blah.deb data.tar.gz | tar zfd - | grep 'Contents differ'
When did I say that I was trusting disk md5sums? I'm trusting the image
copy of the compromised system, the md5sum binaries of the analysis
computer in which the image is stored, and my list of valid md5sums
(downloaded from Debian as described above). I'm not trusting the local
information on the image copy, but it will be useful to pinpoint attack
methods easily.
Do you really want to say that the only way a forensic investigator could
have of checking a hard disk image contents is downloading the _full_
Debian archive in order to compare that to the disk? What if the system is
stable+security updates, how would you remove the false positives in your
above example?
Now, imagine we have this file, and we have the local md5sum database in
the image copy of the compromise system. I could check rather easily:
1.- if the vendor provided md5sum files in the database matches the local
md5 hashes information for files in the system.
2.- if the local files's md5 hashes match the local md5sum database.
3.- if the local files's md5sum match the vendor-provided database and
which packages (even versions, if the database is made of two releases, say
stable and security updates) it belongs to.
4.- if the packages which files seem to belong to (based on md5sum files)
correspond to packages that _should_ be installed in the system (based on
release files).
....
Answering (1) can tell me if the local md5 database has been tampered with
or if packages have been modified (they are not the ones provided in the
releases), (2) can tell me if files have been tampered w/o tampering the
database, (3) can tell me if files have been tampered and the attacker has
tampered the md5 database information for them too, (4) can tell me if the
intruder has used the package mechanism to install old (insecure)
packages...
So, the more information I have (local database+vendor supplied database)
the more I can easily determine what happened in the attack. Notice that I
could even determine information from the fact that the local database has
been tampered with.
Please, do take a look at sleuthkit/autopsy, which is a standard tool for
forensic investigation, to see how some of this is implented. You can't
tell with a straight face that we cannot help this task with already
available software (i.e. debsums) and data that we could generate from the
archive ourselves, instead of forcing an investigator to generate this from
an archive copy himself.
> > So my vote goes to adding md5sums to policy.
>
> We still don't vote on technical issues, thank god.
It was just an expression, obviously. Maybe it's not translatable.
Friendly
Javi
Attachment:
signature.asc
Description: Digital signature