On Tue, 12 Nov 1996, Greg A. Woods wrote:
> from the stock binaries.
> 
> (I've also said this a zillion times.)
> 
> > An example for another dangerous environment variable is IFS.  I don't  
> > know for how long ppl have been preaching that it should be reset  
> > immediately within a script.  However, human nature prevents this preaching  
> > from being successful and you won't accept that this world isn't perfect  
> > but rather accuse others of living in a dreamworld.
> 
> Obviously, which is why /bin/login should not allow it to be overridden.
> 
> ... but then we *knew* that already, no?

But surely any system which depends on /bin/login knowing which variables not
to allow to be overridden is a poor idea?  A quick look over CERT's or 8lgm's
advisories will turn up scads of holes of the sort `program compromises
security when run with environmental variable FOO set to BAR', or `program
does the wrong thing when environmental variable BAZ/user input %s overflows
buffer bat[]'.

The telnet environmental variable hole is a good vendor-independent example
of the former, and the finger bug exploited by the internet worm is a good
vendor-independent example of the latter.  Any list of `dangerous variables'
is inherently a very fragile thing.  Please don't make us depend on one.

It seems painfully clear that any suggestion to allow arbitrary setting of
environmental variables in a suid'ed setting, and especially in one so
vital as login, needs more a more urgent justification than `I thought it
might be useful and couldn't think of anything in the standard distribution
that it would break.'

Can we _please_ lay this suggestion to rest?

--
				Jim Wise
				System Administrator
				GSAPP, Columbia University
				jim@santafe.arch.columbia.edu
				http://www.arch.columbia.edu/~jim
				* Finger for PGP public key *