Re: And now for something completely different... etch!
On Thursday 16 June 2005 08:18, Steve Langasek <firstname.lastname@example.org> wrote:
> > One of the points of the md5sum verification is to ensure that the
> > binaries haven't been tampered with. If one can tamper with the binaries
> > by modifying some file in /var/cache instead, doesn't that just
> > reintroduce the same problem?
> There are two basic reasons why people want md5sums of their binaries: to
> know when their filesystem is eating files, and as an extra layer of
> security to tell them their binaries have been modified by an intruder. In
> the first instance, removing the cache and regenerating it would be
> sufficient to eliminate any corrupted files; in the second instance,
> removing the cache and regenerating it would be sufficient to eliminate any
> trojaned files (though, what a strange attack vector that would be :).
I think that the idea would be:
Prelink changes certain fixed parts of the binary, most of the file is never
changed. The parts that are changed would have their original values stored
so that a checking tool can do a md5 or sha sum of the main part of the file
plus the original values for the parts that prelink changes. Changing the
parts of the file which were changed by prelink such that the md5 or sha
matches even after changing the body of the file would require cracking md5
or sha - this may be possible but is still quite difficult.
But if someone can change the cache of data written by prelink then why
couldn't they also change the program that does the md5 checks to make it
always return a good result?
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page