Date: Thu, 26 Oct 1995 05:00:19 -0700 From: David Greenman <davidg@Root.COM> To: gwk@cray.com Cc: phk@critter.tfs.com, dab@berserkly.cray.com, hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix Message-ID: <199510261200.FAA00275@corbin.Root.COM> In-Reply-To: Your message of "Thu, 26 Oct 95 11:40:08 BST." <199510261040.LAA16603@racer.dkrz.de>
next in thread | previous in thread | raw e-mail | index | archive | help
>> > 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?199510261200.FAA00275>