Re: debsums for maintainer scripts
Javier =?iso-8859-15?Q?Fern=E1ndez-Sanguino_Pe=F1a?= <jfs@computer.org> writes:
> [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?
Thats why I want signatures so even after a compromise and reboot from
a good medium the debs or md5sum lists from the compromised system can
be trusted.
> 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)
Debian can provide such a database completly without any md5sums files
in the deb. They are as it is realy useless.
> > > 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)
Then write such a tool instead of wasting all mirror and users
bandwith and diskspace.
> > 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
If the vendor supplies the list you don't need any list in the debs
themself. Thanks for prooving our point.
> 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
You argue against people who are basically on your site. A known good
list of md5sums is usefull. A md5sums file inside the deb does not
provide this. We agree on that.
> 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.
And only users that want to check md5sum have to download thm.
> > > 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
Thats whats the thread was about most of the time.
> 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
Thats how it is now. in package md5sum files, what this is all about,
doen't change that a bit.
> stable+security updates, how would you remove the false positives in your
> above example?
You read every single file thats changed and find out if that is an attack.
> 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.
That means you throw th local one away and download a known good one.
> 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
(1) downloads you a known good copy which mans downloading all debs
as it is now.
> 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
You vote for providing md5sums files seperatly from the debs and not
in the debs (and you probably would still agree by just providing a
signature for locally stored/generated md5sum file verification). So
your on our side.
MfG
Goswin
Reply to: