According to Ian Dall:
>
>woods@kuma.web.net (Greg A. Woods) writes:
>
>  > If you give me an initial shell (i.e. /bin/sh), I may be able to exploit
>  > some race conditions to gain interactive shell access.  However I won't
>  > have to muck with any environment variables to get them.  If there are
>  > no race conditions to be exploited, then no amount of fiddling with
>  > innocuous(*) environment variables will get me any further, unless of
>  > course you've given me an explicit hole by using some variable in
>  > /etc/profile that you don't first initialize.
>
>  > (*) I.e. variables other than SHELL, PATH, LD_LIBRARY_PATH, or any
>  > others that a grep of the source tree shows might be risky.
>
>Allowing IFS to be changed is famous for making shell scripts
>behave unpredictably.
>

Not only that but there are a raft of buffer overflow exploits that
can be run - they work by finding some statically allocated storage
that an environment variable (or any other user input) is read into
and then carefully overflowing that storage with data that when it
overwrites the stack does something interesting like an exec call to
/bin/sh.  This is how the old fingerd exploit worked, this is how the
current lpd exploit works (from memory).  You cannot protect yourself
just by grepping binaries for "suspect" environment variables because
you don't know if they are being copied in an unsafe manner into
statically allocated storage.  Even with the source catching all of
the instances of unsafe copying is not an easy task.

Why are we thrashing this around at all?  Is there a particular reason
why we need the ability to set environment variables from the login
prompt? 

-- 
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
  "Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.