Date: Tue, 24 Oct 95 10:23:48 CDT From: dab@berserkly.cray.com (David A. Borman) To: davidg@Root.COM Cc: hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix Message-ID: <9510241523.AA05306@frenzy.cray.com>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9510241523.AA05306>