Re: /dev/tcp, and a LD_LIBRARY_PATH question.

[rens () imsi com (Rens Troost)]

> > > > > "hoodr" == hoodr  <hoodr () hoodr slip netcom com> writes:
  >> Second question: How can I write a program that keeps the
  >> LD_LIBRARY_PATH variable from being exploited? i.e. the SUN
  >> 'login' bug where LD_LIBRARY_PATH got exploited. I would ASSUME I
  >> could prevent this by doing something like:
  >> putenv("LD_LIBRARY_PATH"), but that just seems too simple to be a
  >> true fix.  (If it's not complex, it's not right? :)

  hoodr> Don't assume that LD_LIBRAY_PATH is the only variable you
  hoodr> have to worry about.  I was able to easily break "sudo" with
  hoodr> the LD_PRELOAD variable (we've since fixed it by supplying a
  hoodr> brand new environment, instead of re-using the old one).

  hoodr> A strings on /usr/lib/ld.so, show the following items which
  hoodr> are most likley environment variables: LD_LIBRARY_PATH
  hoodr> LD_TRACE_LOADED_OBJECTS LD_PROFILE LD_PRELOAD
  hoodr> LD_SYMBOLS_PUBLIC

  hoodr> Of course only LD_LIBRARY_PATH seems to be documented in the
  hoodr> man pages.  Maybe someone from Sun can comment on what the
  hoodr> rest of these do (please?)

  >> From experimentation, the LD_PRELOAD variable should point to a
  hoodr> library (not a directory of libraries).  That library will be
  hoodr> loaded before the standard library path (or LD_LIBRARY_PATH)
  hoodr> is searched.



LD_PRELOAD allows you to override certain symbols from a library
without having to provide teh entire library. Great for shipping quick
bugfixes and economizing on space.

-Rens