Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
Bugtraq archives for 4th quarter (Oct-Dec) 1994: Re: /dev/tcp, and a LD_LIBRARY_PATH question.

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

Pat Myrto (rwing!patole.cdac.com)
Sat, 3 Dec 94 13:49:50 PST

"In the previous message, Rens Troost said..."
> >>>>> "hoodr" == hoodr  <hoodrhoodr.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? :)

Its a good idea to write a routine to scrub *ALL* LD_* environment
varibles first thing in any SUID program.  ESPECIALLY any that
exec's another program with any kind of privilege.

One of the few things of use from CERT is an advisory that has a
sample function to do this.  Its done in such a way that added ones
are still scrubbed (it tests only for 'LD_' and if the first 3 chars
match that, the variable is scrubbed by moving the next one up
into its place, and likewise thru the array, and putting a null
pointer in the vacated last position.

I don't recall the advisory number, its one discussing login, and su.

patrwing  [If all fails, try:  rwing!pateskimo.com]  Pat Myrto - Seattle WA
"No one has the right to destroy another person's belief by demanding
empirical evidence."  --   Ann Landers, nationally syndicated advice columnist
and Director at Handgun Control Inc.