Date: Thu, 26 Oct 1995 08:27:02 -0400 (EDT) From: Robert Watson <robert@fledge.watson.org> To: David Greenman <davidg@Root.COM> Cc: gwk@cray.com, phk@critter.tfs.com, dab@berserkly.cray.com, hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix Message-ID: <Pine.BSF.3.91.951026082137.6927C-100000@fledge.watson.org> In-Reply-To: <199510261200.FAA00275@corbin.Root.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
Maybe we should be considering a .telnetrc which can be configured to pass the variables of choice on from the incoming session to the shell.. As in, on the system being telneted TO, have a .telnetrc file something like this: ---cut--- environment DISPLAY TERM ---cut--- Or, if we wanted to get really exciting (or at least, overly complicated) have a variable that sets the imported variables :). The best solution is really just to skip environmental implementation until after login is done, passing them on in some way to the shell session. Possibly by implementing something in the (eww) manner of the DOS environmental block, passed on the child processes, but not actually used by the parent. Another option is to drop environmental variable passing.. As a person who uses their FreeBSD/X system to access a lot of Sun systems, I can't pass the variables anyway, as their telnetd doesn't pick them up. This is a kind of biased suggestion, as due to the objections to this option already, one can guess that there are users around :) On Thu, 26 Oct 1995, David Greenman wrote: > >> > At the moment, I'm seriously considering adding a switch to shut off the > >> > feature in FreeBSD's telnetd and making it the default in inetd.conf. > >> > >> YES! > >> > >> -- > >> Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. > > > >NO! > > > >I'd rather like to see a statically linked login, which would plug the > >hole without any side-effects. > > Have people not been listening? The problem I keep bringing up has to do > with environment variables used in libc. Building login static doesn't affect > this. My original message is attached. > > -DG > > To: dab@cray.com > cc: security@freebsd.org, hartmans@mit.edu > Subject: telnetd fix > From: David Greenman <davidg@Root.COM> > Reply-To: davidg@Root.COM > -------- > Dave - > > 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: > > HOME > TZNAME > TZ > LANG > TMPDIR > NLSPATH > RES_OPTIONS > HOSTALIASES > LOCALDOMAIN > PATH_LOCALE > > Login(1), in particular, delays for a considerable amount of code before > destroying it's inherited environment. While some of these variables may not > be used in login(1), or may not in themselves be usable in a security attack, > the potential problems may exist for some of them. The variables related to > the resolver are troubling to start with and the path-related ones could > conceivably be used to read protected files. ...and of course there is the > issue of future vulnerability when new variables are added in the libraries or > in the program startup code (crt0). > 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. > Thanks for listening... > > -DG
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.951026082137.6927C-100000>