Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Oct 1996 17:13:41 +0100
From:      Jan-Hein Buhrman <jh@tangram.xs4all.nl>
To:        joerg_wunsch@uriah.heep.sax.de
Cc:        marcs@worldgate.com, freebsd-bugs@FreeBSD.org
Subject:   Re: docs/1383
Message-ID:  <199610271613.RAA01836@tangram.xs4all.nl>
In-Reply-To: <199610232049.WAA27794@uriah.heep.sax.de> (j@uriah.heep.sax.de)

next in thread | previous in thread | raw e-mail | index | archive | help
>>>>> "J\"org" == J Wunsch <j@uriah.heep.sax.de> writes:

> As Marc Slemko wrote:
>> > There are not much risks with `interpreted executables' other than
>> > the one described there.  This one however can easily be avoided by
>> > suggesting
>> > 
>> >         #!/bin/sh
>> >         exec /usr/sbin/ppp -direct
>> > 
>> > in the man page.
>> 
>> Not true.  Doing so will NOT avoid the problem.

> Ahhhrg.  I should have read the entire audit-trail before.  Now i see
> that i've already looked at it earlier...

[ About instructing the server side of the telnet session setting the
  envvar "ENV" to "/etc/shells" (see sh(1)), even before a connect is
  initiated. ]

> The shell should really have the equivalent of csh -f.  (sh -q?
> Any opinions on this?)

IIRC, the Korn Shell had a `-p'-option that more-or-less provides this
functionality.  Since this ENV-thing is also a ksh-derived `feature',
perhaps that option could be added.

BTW, IMHO it's a _bad_ thing that Bourne-shell scripts can now
suddenly change drastically in their behaviour (because the caller has
a "$ENV" that is not according to the advice mentioned in the sh
man-page) without a sane possibility for the script writer currently
to do something about it, I always believed that by sticking to plain
Bourne-Shell scripts I would never have any troubles like a $ENV-file.

Tomorrow they will tell me that the `.' command (for sourceing other
files) will suddenly use the PATH envvar (a major incompatibility
between ksh and sh).

Probably this whole ENV-thing comes from the POSIX people, otherwise I
would vote for *not* source-ing $ENV at all when the shell is not
running interactively (i.e. $- contains no `i') unless some other flag
(having the opposite meaning of ksh's `-p') is set in the interpreter
line. (I'm thinking of all the currently existsting shell scripts that
need be changed otherwise).

One other thing: Aren't there any other security-related risks with
allowing stuffing the environment even before an actual login is
performed (can't really come up with something, but I'm thinking of
some classic ones, like IFS, LD_*)?

> The only alternative by now to your attack is putting a ``kill 0'' on
> top of /etc/shells. ;-)

> -- 
> cheers, J"org

Regards,

-jh



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199610271613.RAA01836>