On Fri, Nov 22, 2002 at 11:31:35AM +0100, der Mouse wrote:
> > - Every binary, including executable and shared object, has .csum
> >   section inserted by ld(1) at compile time. It is 32-bit long and
> >   used for storing checksum (CRC32) of the binary.
> 
> > - Actual prebinding and prerelocation is done by ld.elf_so(1). After 
> >   ld.elf_so(1) loads a binary for the first time, it creates a disk
> >   file in /usr/libexec/reloc (say it "cache") and writes all of the
> 
> Shudder.  This sounds like a security disaster waiting to happen.  All
> of a sudden, most of your system security is dependent on one directory
> keeping its sticky bit.  It is also vulnerable to someone writing
> forged preloaded data there before the real executable with that hash
> is run.  Anyone who can read the executable and thus discover its hash
> can perform this attack.  (Note that this is not helped by using a
> cryptographically strong hash instead of a simple CRC, nor is it helped
> by removing the read bits from the directory.)

That's the reason why I added "security considerations" to disadvantages
list. ;-)

For now, the only method I can think of is:

- to have a separate prebind(1) instead of doing prerelocation in
  ld.elf_so. It is the same as prelink on Red Hat, except that it stores
  prerelocated entries as a separate file under /var/db/reloc. So when
  ld.elf_so executes, it can only read files there, not write one.
  With this method, prebind(1) should be run by root when a new binary is 
  installed in the system.

or

- per-user reloc/ directory. I don't think it good, though.

> 
> I also expect hash collisions in this directory if you use a hash only
> 32 bits long; the birthday count is only 64K, which is not implausible
> if this is done for all executables.
> 
> In another message,
> 
> > I thought about MD5 as well, but it is too long to be used as a file
> > name.
> 
> An MD5, expressed in hex, is only 32 characters (never mind something
> more compact like base-254; in any base from 185 to 254, it's only 17
> bytes).  You could express it in _binary_, even, and still use it as a
> filename.

I will try it when I actually implement code.

Jun-Young

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