From owner-freebsd-security Tue Oct 24 07:11:08 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA13651 for security-outgoing; Tue, 24 Oct 1995 07:11:08 -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 HAA13646 for ; Tue, 24 Oct 1995 07:10:59 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id HAA06046; Tue, 24 Oct 1995 07:10:40 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id HAA27483; Tue, 24 Oct 1995 07:07:44 -0700 Message-Id: <199510241407.HAA27483@corbin.Root.COM> To: dab@cray.com cc: security@freebsd.org, hartmans@mit.edu Subject: telnetd fix From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 07:07:43 -0700 Sender: owner-security@freebsd.org Precedence: bulk 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