From owner-freebsd-security  Tue Oct 24 08:23:31 1995
Return-Path: owner-security
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id IAA17411
          for security-outgoing; Tue, 24 Oct 1995 08:23:31 -0700
Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA17401
          for <security@freebsd.org>; Tue, 24 Oct 1995 08:23:26 -0700
Received: from frenzy.cray.com (frenzy.cray.com [128.162.84.21]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id KAA26366 for <security@freebsd.org>; Tue, 24 Oct 1995 10:23:23 -0500
Received: by frenzy.cray.com
	id AA05306; 4.1/CRI-5.6; Tue, 24 Oct 95 10:23:48 CDT
Date: Tue, 24 Oct 95 10:23:48 CDT
From: dab@berserkly.cray.com (David A. Borman)
Message-Id: <9510241523.AA05306@frenzy.cray.com>
To: davidg@Root.COM
Subject: Re: telnetd fix
Cc: hartmans@mit.edu, security@freebsd.org
Sender: owner-security@freebsd.org
Precedence: bulk


>    Hi; I've been thinking about the telnetd security patch that was recently
> sent out. I've been watching the list of "vulnerable" environment variables
> grow daily...I really think that excluding certain environment variables is the
> wrong approach to solving the problem. I think it is is much wiser to do an
> inclusive test rather than an exclusive one - in other words, only allow
> setting specific environment variables such as DISPLAY and TERM (perhaps those
> two comprise a complete list - I can't think of any legitimate others). The
> reasoning is simple: while you may catch the current set of environment
> variables related to shared library spoofing, a quick search through _just_
> libc in FreeBSD reveals yet another list of worries:
...
>    So the bottom line is that I strongly believe that excluding certain sets
> of variables isn't the right approch and I hope you'll reconsider the proposed
> bugfix for telnetd.

It's not that simple.  The whole point of the environment option is
to allow the passing of arbitrary environment variables, because you
don't know what poeple may want to pass through.  Changing telnetd to only
allow an enumerated list of variables through means that if I have some
private application that looks at an environement variable, and I want
to propogate that variable, I then have to go to the administrator and
ask that my personal variable be added to the list.  Depending on the
system/administrator, that can be a hassel and take time, and I'd probably
just go back to setting things up in a .profile or .cshrc through some
home-brew out-of-band mechanism, defeating the whole purpose of having
the environ option in telnet.

The fact of the matter is that what telnetd really wants to do is to
put things into the users environment, not the environment of login.
However the only current mechanism for doing that is to put things into
the environment of login, which then passes them on to the login shell.

The current fix does the minimal amount of work needed to solve the
immediate problem, and a better long-term solution can be developed
without the pressure of getting out a fix ASAP.

			-David Borman, dab@cray.com