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)....

Only root user can get write access to system directories. If you could
replace libc.so with a malicious one, why not explode the whole system
with 'rm -fr /'?

Also RelCache is nothing more than relocated .data section and part of
.bss section just after relocation is done (at this time .bss is mostly
filled with zero). It contains no dynamic data the application stores
in it while it's running.

Jun-Young

-- 
Bang Jun-Young <junyoung@netbsd.org>