On Wed, Dec 04, 2002 at 12:52:22AM +0100, der Mouse wrote:
> > The sole purpose of this identifier is to ensure that ld.so does not
> > mistake one legitimate .so file for another.  Deliberate attempts to
> > generate hash collisions are beyond the scope; this is not a security
> > function, we simply want reasonable assurance that the prebinder will
> > not hand you the symbols for the wrong shared object file because
> > they happened to have the same unique identifier computed from their
> > contents and stamped into them.
> 
> I must be missing something.  How is it not a security problem if you
> get the symbols that go with a .so file of the attacker's choice rather
> than the ones that go with the .so you wanted to use?  At the very
> least, it sounds like a trivial DoS to me, and probably worse
> (consider, for example, arranging to have strncpy resolve to strcpy's
> code)....

Ding!  Now, here's a reason why the .so file's metadata *must* be used;
at the very least, the file's owner and permissions, but really, you
actually also need the dev/inum/generation triple that uniquely identifies
a file in the filesystem to the kernel (at which point, I'm tempted to
ask "why the checksum?" but I suppose it serves as a decent sanity 
check).

At that point, you might as well just grab the mtime, too -- you get it
all for the cost of one "struct stat".

Thor