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

Re: And now for something completely different... etch!

On Thu, Jun 16, 2005 at 01:51:04PM +1000, Russell Coker wrote:
> regarding prelink

> On Thursday 16 June 2005 08:18, Steve Langasek <vorlon@debian.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.

In which case, /var/cache is absolutely the wrong place to store those
original values, since they can't be regenerated based on information on the
rest of the system.

I figured people were going the other way around with this, and suggesting
that prelink store its *output* in /var/cache, with support in the dynamic
loader for merging it in at the correct moment.

> 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?

They can, but I've never seen a rootkit with that level of sophistication;
and if there was one, there's still the option of booting from read-only
media to check (which is the only safe way to audit your system anyway).

Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature

Reply to: