Re: a point is being missed

[rmtodd () servalan servalan com (Richard Todd)]

In message <199511040039.AA195075591 () l-ecn046 icaen uiowa edu>Douglas Siebert writes:
> I disagree quite strongly.  Assuming your implementation of shared libraries
> is sane, like HP's, you should not even have to worry about this class of
> attacks.  HP requires a compile-time option to the linker to ALLOW changing
> the library search path via an environment variable.  You can also change
> this attribute on an existing binary using the 'chatr' (change attribute)
> command.

HP does that?  Cool.  That's exactly the sort of thing I'd like to see.

It's struck me for some time that all the zillions of security holes
we've seen with LD_* exist because the whole LD_* system violates a
fundamental axiom of Unix security.  It used to be that the only way you
could change the code that got executed when you ran a program is to write
to the executable file.  That provided a certain level of security, in that
in order to change the way, say, /bin/login works, you have to have
previously broken root via some other means. :-)  But now with the LD_*
variables around, what code gets executed when you run an executable depends
on what's in the environment, which is something that can be altered by
malicious users.   I seriously think that the people out there supplying
Unix systems ought to make the default be that LD_* environment variables
have no effect.  Yeah, it's sometimes useful to have the ability to change
what libraries a shlib-using executable is using, but it should be through
some mechanism that requires changing to the executable file (like the
'chatr' mechanism the HPs have, or simply having the pathnames for the
libraries be at standardized places in the executable -- at addrs given by
some standard symbol, say -- so you can have a program that changes what
libs a given executable will use.)  That way, the axiom that you can't change
what code a program executes without write access to the executable still
holds.

  It occurs to me that it might not even be that hard to implement the
equivalent of the 'chatr' attribute on other Unix-type systems.  I gather
that somewhere in the startup code for any program linked with shlibs there's
code that loads in the dynamic linker (ld.so) and calls it, right?  Well, all
you need is to have two versions of ld.so, one respecting the LD_* variables
and one that doesn't.  Have the pathnames of the two versions differ by a
single letter.  Then all chatr needs to do is find that pathname in your
executable and flip that one byte in the pathname to make your executable use
the 'dangerous' ld.so instead of the safe one.

--
Richard Todd    rmtodd () mailhost ecn uoknor edu        rmtodd () servalan uucp
          New Improved Domain: rmtodd () servalan servalan com