The newest debsums from Sid can do a daily check for md5 disagreement. Useful
for security?

This check flags a load of missing files which are either obsolete -- maybe I
once had 'em but they are long gone -- or ... I never had 'em.

Two prime examples:

The former, Sun Java 1.5 stuff. Has been superseded by 1.6 and this was always
be Sun's installation rather than anything from Debian. The latter
/usr/loca/Adobe . . . acrobat stuff. I never had a local version. Most entries
seem to be internationalization stuff.

There is a (now empty) /etc/debsums-ignore. If this can be set to exclude
directories, I can easily suppress the check on these files. Question is where
the program gets the info to look for them in the first place?



--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

On 2008-10-27 08:24 +0100, David Baron wrote:

> The newest debsums from Sid can do a daily check for md5 disagreement. Useful
> for security?

Not really. An attacker that can modify system files can and will also
update the md5sums under /var/lib/dpkg/info. Besides, scanning each and
every installed file takes _really_ long, so it is not recommended to
run this daily.

> This check flags a load of missing files which are either obsolete -- maybe I
> once had 'em but they are long gone -- or ... I never had 'em.
>
> Two prime examples:
>
> The former, Sun Java 1.5 stuff. Has been superseded by 1.6 and this was always
> be Sun's installation rather than anything from Debian. The latter
> /usr/loca/Adobe . . . acrobat stuff. I never had a local version. Most entries
> seem to be internationalization stuff.

Do you have localepurge installed? It will delete many l10n files that
debsums will report then.

> There is a (now empty) /etc/debsums-ignore. If this can be set to exclude
> directories, I can easily suppress the check on these files.

That's not how it works, unfortunately. These files will still be
checked, only the final output is filtered. Have a look at debsums'
cron script to convince yourself if you don't trust me.

> Question is where
> the program gets the info to look for them in the first place?

>From the *.md5sums files under /var/lib/dpkg/info.

Sven


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Sven Joachim wrote:

On 2008-10-27 08:24 +0100, David Baron wrote:

The newest debsums from Sid can do a daily check for md5 disagreement. Useful
for security?


Not really. An attacker that can modify system files can and will also
update the md5sums under /var/lib/dpkg/info. Besides, scanning each and
every installed file takes _really_ long, so it is not recommended to
run this daily.

This check flags a load of missing files which are either obsolete -- maybe I
once had 'em but they are long gone -- or ... I never had 'em.


Two prime examples:

The former, Sun Java 1.5 stuff. Has been superseded by 1.6 and this was always
be Sun's installation rather than anything from Debian. The latter
/usr/loca/Adobe . . . acrobat stuff. I never had a local version. Most entries
seem to be internationalization stuff.


Do you have localepurge installed? It will delete many l10n files that
debsums will report then.

There is a (now empty) /etc/debsums-ignore. If this can be set to exclude
directories, I can easily suppress the check on these files.


That's not how it works, unfortunately. These files will still be
checked, only the final output is filtered. Have a look at debsums'
cron script to convince yourself if you don't trust me.

Question is where
the program gets the info to look for them in the first place?



From the *.md5sums files under /var/lib/dpkg/info.


Sven




MD5s are not useful for security purposes any more. They are too easy
to duplicate with a malicious file. There are demonstrations of this
out there, one guy produced two different valid PDFs with the same MD5.


(Any file is a large number. The hash calculation produces a *much*
smaller number from the big number. Trivial analogy: n mod 7 = ?
produces an infinite number of sixes. Collisions with any similar
scheme are inevitable. The trick is to make it hard to find valid
malicious collisions. MD5 is no longer sufficiently computationally
intensive to prevent the substitution of malicious files. We need to
move on to better solutions.)


Mark Allums





--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

2008/10/27 Mark Allums <mark@allums.com>:
>> On 2008-10-27 08:24 +0100, David Baron wrote:
>>
>>> The newest debsums from Sid can do a daily check for md5 disagreement.
>>> Useful for security?
>>
[...]
> MD5s are not useful for security purposes any more. They are too easy to
> duplicate with a malicious file. There are demonstrations of this out
> there, one guy produced two different valid PDFs with the same MD5.

To be fair, it is easier to produce two files having the same checksum
than creating a second file having a fixed checksum. But sure, MD5
should be considered broken.

And as Sven pointed out, if the checksums are stored on the same
machine, the fact that things seem to verify could be because the
attacker has replaced the checksum. This scheme is broken for any hash
function, not only MD5 and others that are broken. The same argument
could be applied to any "solution" using the possibly-tampered-with
machine to verify itself. How can you possibly trust the result of
such an operation?

Take care,
Martin


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Martin Ågren wrote:

2008/10/27 Mark Allums <mark@allums.com>:

On 2008-10-27 08:24 +0100, David Baron wrote:


The newest debsums from Sid can do a daily check for md5 disagreement.
Useful for security?

[...]

MD5s are not useful for security purposes any more. They are too easy to
duplicate with a malicious file. There are demonstrations of this out
there, one guy produced two different valid PDFs with the same MD5.


To be fair, it is easier to produce two files having the same checksum
than creating a second file having a fixed checksum. But sure, MD5
should be considered broken.

And as Sven pointed out, if the checksums are stored on the same
machine, the fact that things seem to verify could be because the
attacker has replaced the checksum. This scheme is broken for any hash
function, not only MD5 and others that are broken. The same argument
could be applied to any "solution" using the possibly-tampered-with
machine to verify itself. How can you possibly trust the result of
such an operation?

Take care,
Martin



Yeah. All true. SHA-512 will last awhile, maybe, though. As long as
you aren't already compromised. If you are, the game is already over.


Mark A.




--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org