[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debsums fun



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





Reply to: