From owner-freebsd-security Thu Oct 26 05:01:01 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA03498 for security-outgoing; Thu, 26 Oct 1995 05:01:01 -0700 Received: from Root.COM (implode.Root.COM [198.145.90.17]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA03493 for ; Thu, 26 Oct 1995 05:00:58 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id FAA00521; Thu, 26 Oct 1995 05:00:57 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id FAA00275; Thu, 26 Oct 1995 05:00:21 -0700 Message-Id: <199510261200.FAA00275@corbin.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 In-reply-to: Your message of "Thu, 26 Oct 95 11:40:08 BST." <199510261040.LAA16603@racer.dkrz.de> From: David Greenman Reply-To: davidg@Root.COM Date: Thu, 26 Oct 1995 05:00:19 -0700 Sender: owner-security@freebsd.org Precedence: bulk >> > 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 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