>>> [...] this is not a security function, [...]
>> 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?
> maybe i'm missing something... how does one actually perform this
> attack?

Someone installs new package <foo>, including libfoo.so.

Before anything is run using libfoo.so, the attacker reads libfoo.so
and computes the checksum for it.  Attacker then constructs a .so file
with the same symbols as the real one, but with their values pointing
elsewhere (eg, my suggestion about making strncpy point to strcpy's
code).  The attacker then fiddles the file's contents so as to produce
the same checksum as the real one.  (Thsi is where weak hashes are
relevant.  For example, this step is trivial for CRCs.)

Attacker then (creates and) runs a program that uses this .so.  The
cache kicks in and creates a cache entry for that checksum, with the
attacker's symbol values.  (Note that eh program doesn't have to do
much with it; merely causing the dynamic loader to load it is enough.)

Attacker now waits.  Eventually, someone runs something that uses the
real libfoo.so.  The dynamic linker finds the bogus cache file, sees it
has the right checksum-- and uses its symbol values.  Oops.

Thus, you can't depend on just the hash as the file identifier unless
you use a cryptographically strong hash.  Thus people commenting that
one should include the inumber, the mtime, etc.  (Note that the mtime
is about as helpful at defeating this attack as a CRC is, ie, not at
all.  The ctime might be worth using in that regard....)

You also need to be careful that the attacker can't compute a bogus
cache file with *all* the correct identifying bits (checksum, inumber,
whatever) and drop it into the cache directory; stopping this requires
either per-user cache directories, or mode 755 root and only root can
create a new cache entry, or some such, regardless of the checksum
algorithm and regardless of what other identifying bits you include.

Of course, there is fundamentally a race here in that the attack can be
carried out only after the real .so is created but before a legitimate
cache entry gets created (ie, approximately, before it's used).
However, that window of opportunity can be more or less arbitrarily
wide, since it depends in large part on human actions.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B