Date: Tue, 24 Oct 1995 07:07:43 -0700 From: David Greenman <davidg@Root.COM> To: dab@cray.com Cc: security@freebsd.org, hartmans@mit.edu Subject: telnetd fix Message-ID: <199510241407.HAA27483@corbin.Root.COM>
next in thread | raw e-mail | index | archive | help
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?199510241407.HAA27483>