From owner-freebsd-security Tue Oct 24 06:16:20 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id GAA10831 for security-outgoing; Tue, 24 Oct 1995 06:16:20 -0700 Received: from time.cdrom.com (time.cdrom.com [192.216.222.226]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id GAA10825 for ; Tue, 24 Oct 1995 06:16:14 -0700 Received: from localhost (localhost [127.0.0.1]) by time.cdrom.com (8.6.12/8.6.9) with SMTP id GAA11891 for ; Tue, 24 Oct 1995 06:15:59 -0700 Prev-Resent: Tue, 24 Oct 1995 06:15:58 -0700 Prev-Resent: "security@freebsd.org " Received: from tertius.mit.edu (TERTIUS.MIT.EDU [18.245.0.93]) by time.cdrom.com (8.6.12/8.6.9) with ESMTP id AAA10911 for ; Tue, 24 Oct 1995 00:24:38 -0700 Received: (from hartmans@localhost) by tertius.mit.edu (8.6.12/8.6.9) id DAA15744; Tue, 24 Oct 1995 03:24:22 -0400 Date: Tue, 24 Oct 1995 03:24:22 -0400 From: Sam Hartman Message-Id: <199510240724.DAA15744@tertius.mit.edu> To: security-alert@sgi.com, miguel@sgi.com, security-alert@hp.com, rich.boren@cxo.mts.dec.com, eichin@cygnus.com, bjaspan@cam.ov.com, volkerdi@wcarchive.cdrom.com, mycroft@mit.edu, bruce@pixar.com, tobias@server.et-inf.fho-emden.de, ache@astral.msk.su, jkh@time.cdrom.com, bugs@redhat.com, mark.graff@eng.sun.com CC: tytso@mit.edu, jis@mit.edu, hartmans@mit.edu, brlewis@mit.edu, jhawk@mit.edu, cert@cert.org, lrr@cert.org Subject: timely: details on announcement of telnetd vulnerability Reply-to: hartmans@mit.edu, tytso@mit.edu Resent-To: security@freebsd.org Resent-Date: Tue, 24 Oct 1995 06:15:58 -0700 Resent-Message-ID: <11889.814540558@time.cdrom.com> Resent-From: "Jordan K. Hubbard" Sender: owner-security@freebsd.org Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- History and Preface NOTICE: Because we have found a temporary work around, Theodore Ts'o has asked me to announce this bug publicly next Tuesday. The announcement will be issued soon after 10:30 EDT on Tuesday, October 31, 1995. If your patch isn't listed, tell me about it by Monday, October 30. If your system is vulnerable and the suggested quick fix won't work, it's probably in your best interest to tell me this too; that way your users won't get a false sense of security. For such reports to be useful, I need to receive them by this Thursday evening. Also, if there are comments that can help the structure of this memo as it evolves from a memo for vendors to a bug description/announcement, let me know. I know the following changes will be made before the announcement: * The 'Public Exposure' section will go away -- the announcement will be very public, so exposure will no longer be an interesting issue. * Information in 'Availability of Patches' regarding the announcement date will go away. * A section describing how to test for the bug (not an exploit, although it'll probably have to be close enough that anyone who understands how to build a new library on their platform can figure out an exploit) will be added. * The section on verifying patches will be cleaned up/expanded. Things you should note that have changed: * Bugs have been found in the first Borman patch, and in the sample patch I originally sent out. * A few more environment variables have been added. The latest is ELF_LD_LIBRARY_PATH, which, according to Linux documentation is used as an ELF library search path. The code tends to disagree with the documentation, using LD_ELF_LIBRARY_PATH; I'm still waiting to hear from H. J. Lu on this one. * Other information has been added about patches. * Clarification: if you require external authentication, only your valid users can break in. On Sunday, October 15, I discovered a bug in some versions of telnetd on some platforms that allows a user making a connection to cause login to load an alternate C library from an arbitrary location in the filesystem of the machine running telnetd. In the case of machines mounting distributed filespaces such as AFS or NFS, containing publicly writable anonymous FTP directories, or on which the user already has a non-root account, it is possible to gain root access. The problem is that telnetd will allow the client to pass LD_LIBRARY_PATH, LD_PRELOAD, and other run-time linker options into the process environment of the process that runs login. If the runtime linker honors these options for login, the attacker can cause a custom libc to be loaded. Such a libc could, for example, start a shell whenever some function like crypt() is called. If login calls this function before the setuid call, then the attacker will gain root access. Note that the user must be able to convince telnetd to run login in order for this attack to be successful. In particular, if an authentication system such as Kerberos is employed, and the telnetd requires authentication, then only users with valid accounts will be able to use this attack. Quick Fix Most runtime linkers treat set user-id and set group-id programs specially: for these programs the environment variables are ignored when the program is run by a user other than the owner of the file, or by someone in a group other than the primary group of the file. Even though login is often set user-id, the environment variables are used because it is run by telnetd which runs as root. However, if you force login to be set-uid another user, or set-gid, you can cause the runtime linker to ignore the environment variables, protecting your system from this attack until your vendor prepares a patch. It turns out that login needs to be root, so making login set-uid doesn't work. However, there is nothing that stops you from making login set-gid. To do so, follow these steps: 1) Create a new group (you might want to call it 'login', 'telnet_bug', tnbug', '__login' or something of the sort). In the rest of this document, I will assume that you have called the group 'login'. Make sure the group doesn't already exist, and make sure that no other programs are moved into this group. For information on how to create a group, consult your vendor's manuals and the man page for /etc/group. 2) Find your login program; it is often /usr/bin/login or /bin/login. I will assume here that it is /bin/login. Under AIX and some other operating systems, login may be a symlink to another program; we are interested in changing the group of the actual program, not of the symlink. 3) Look at the current permissions on login: bash$ ls -l /bin/login lrwxrwxrwx 1 root system 13 Mar 8 1994 /bin/login -> /usr/sbin/tsm bash$ ls -lL /bin/login -r-sr-xr-x 3 root security 59217 Aug 23 1994 /bin/login bash$ Note that because I am running on an AIX system, I gave the -L option to the second ls in order to trace through the symlink and find the real login. You should remember what group login is in so you can change things back after you get a a vendor patch. 4) Change the group of login and set the set GID bit: bash$ su root's Password: bash# chgrp login /bin/login bash# chmod g+s /bin/login bash# ls -lL /bin/login -r-sr-sr-x 3 root login 59217 Aug 23 1994 /bin/login bash# Environment Variables that Matter This is not an exhaustive list of environment variables telnetd should filter, but it does contain several of the key variables on systems used at MIT and by people with whom I have consulted: LD_LIBRARY_PATH: At least Solaris, SunOS, NetBSD, Linux and Digital Unix use this as the path to look for shared libraries in. LD_PRELOAD: Solaris and possibly others load these object modules into the address space of the process before loading other shared libraries. LIBPATH: AIX uses this to locate its shared libraries. ELF_LD_LIBRARY_PATH: May be used by the Linux Elf loader; similar to LD_LIBRARY_PATH in function. LD_AOUT_LIBRARY_PATH: Another Linuxism from ld.so-1.7.3. Same as LD_LIBRARY_PATH but only for a.out libraries. _RLD_ROOT: Digital Unix uses this to specify a prefix prepended to library paths stored inside executables. _RLD_LIST: A list of objects dynamically loaded into an executable by Digital Unix. _RLD_*: Used by Digital Unix and SGI. There are several apparently undocumented variables in /sbin/loader on Digital Unix and in the SGI runtime linker. LD_*: Several other variables have special meaning to certain operating systems. Stripping all these variables would probably be a good idea. IFS: It is possible that setting IFS could cause damage in environments where the user logs into an account that runs a shell script instead of granting full access. Affected Telnetds All telnetds derived from the Telnet package distributed by David Borman allow the environment options to be passed. Mr. Borman has released a patch for the problem as of October 19. The patch released on October 19, while secure, has a bug that prevents any telnet environment options from being handled. Another patch was released on October 23 that appears to work; see below for details. Besides his original release, here are a list of operating systems and security packages I'm aware of that include derivatives of this work: * NetBSD and FreeBSD are distributed with a vulnerable telnetd. (See below for patch info) * The telnet94 with the fixed Kerberos version 4 authentication and encryption distributed by MIT on net-dist.mit.edu and used in MIT's Athena computing environment. (see below for patch location) * The version of telnetd maintained in the Kerberos version 5 distribution by MIT. (patch available) * The Cygnus Network Security V4 95q1 Free Network Release includes a vulnerable telnetd. (Previous releases did not contain telnetd.) A patch has been released. * Openvision's OVSecure may contain a telnetd that is vulnerable. Other Vulnerable Telnetd Implementations This problem is not unique to code derived from the Borman telnet distribution. Other vulnerable implementations are known to include: * SGI Irix 5.3 * Digital Unix. The telnetd distributed with stock Digital Unix appears to be vulnerable. * Linux. The telnetd distributed with Slackware Linux appears to be vulnerable, although I have not verified this. The maintainers of Debian GNU/Linux confirm their telnetd is vulnerable and released a patch; see below. Telnetds that Work Below is a list of operating systems which come with telnetds that we know are not vulnerable. * SunOS 4.1.4. The Sunos 4.1.4 telnetd does not support passing of environment variables, so it is not vulnerable. * IBM AIX 4.1. This telnetd does not support environment options. * BSDI's BSD/OS. While the telnetd will pass any environment option, there doesn't appear to be an option to override the shared library path, so BSD/OS is probably not vulnerable. On October 19, Dave Borman confirmed that BSDI is not vulnerable to the attack, although the telnetd will accept any environment variable. * Telnetd on other systems that do not support shared libraries. This includes DEC Ultrix, and Cray Unicos. Note that both AIX and SunOS can be vulnerable if the stock telnetd is replaced. Also, note that the stock Solaris telnetd has not been tested. Availability of Patches This is a list of patches I'm aware of at this time. As you develop a patch for your product/platform, please let me know; considering free operating systems affected by this problem, widely announcing the bug once patches are available is very important. Nevertheless, it is important that we cooperate in timing the announcement of patches so that all can be announced within a short time range. Hopefully, I will be able to wait until October 31 before announcing the bug, but if it becomes widely known (say, for example, discussed on bugtraq), I will announce the patches I know about at that time. Note that these patches are provided as-is, without any guarantee of correctness or security on the part of MIT, myself, or the patch creator. They are provided in a spirit of cooperation, not as a guaranteed fix. * On October 19, David Borman released a new version of his telnet package, containing a fix to the problem. This original patch disabled passing environment options entirely, but was revised on October 23. The revised patch, and instructions for obtaining it are contained at the bottom of this message. Note that this patch does not deal with the possibly problematic ELF_LD_LIBRARY_PATH. * Greg Hudson checked a patch into the NetBSD-current source tree. This patch will be incorporated by any NetBSD-current users who update to the current telnetd. It will be in the NetBSD 1.1 release. NetBSD developers have not indicated whether they plan on releasing a patch for NetBSD 1.0 users. Note that the sample NetBSD patch distributed with an earlier version of the memo was incomplete; the version in the source tree as of October 18 is correct. * Sam Hartman patched the upcoming release of Kerberos 5. In addition, patches were generated against Kerberos 5 beta 5 and beta 4-3. * Mark Eichin prepared patches for CNS. These patches will be available on the Cygnus web site ; support customers are being contacted directly. * Peter Tobias, released a patch for Debian GNU/Linux. This patch can be found in the networking utilities at ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.20-1.deb Note that this patch does not currently deal ELF_LD_LIBRARY_PATH. * Andrey A. Chernov released a patch for FreeBSD, but did not include an URL where the patch could be obtained. * Bruce Lewis is preparing a patch for the MIT-distributed Athena telnet/telnet95. His patch is currently available within MIT and should be available soon in the version of telnet on net-dist.mit.edu. Public Exposure This problem is believed not to have wide circulation, and I am not aware of any incidents of illicit penetration. However, it has received public exposure in three places. First, Richard Basch's patch was inadvertently sent to the krb5-bugs mailing list, which is small but public; a publicly readable archive is maintained on an MIT Discuss server. In response to this exposure, the MIT Student Information Processing Board's Linux development group released a new kerberos package, including a fixed telnetd. The announcement of this package indicated the existence of a telnet security hole; SIPB's sources are publicly readable to the MIT community. Greg Hudson's patch to NetBSD was included in an automatic summary of source changes sent to the source-changes@netbsd.org mailing list. The summary said that the patch prevented telnetd from setting dangerous environment variables. Finally, David Borman's announcement of the new version of telnet was posted to several public lists on October 19. The announcement did not say anything about a security hole, nor did it contain a diff. However, a diff is available at the Cray ftp site. Verifying a Patch In the process of talking to vendors, distributing patches, and getting feedback, I've come up with a lot of 'almost solutions' -- patches that are good enough to make you think they work, but that can be compromised. * A clever trick to get around exact match patches is to embed an equals sign in a variable name. For example, ask your client to send an option requesting that the variable LD_LIBRARY_PATH=/home/hartmans/exploits/sun4lib: be set to the value invalid:/lib:/usr/lib. Naturally, the call to setenv in telnetd adds another =, but that's soaked up by 'invalid', and I still get to break into the system. I.E. Deal with variable names containing equals signs (=). * At least in the Borman BSD telnet, there are two calls to setenv: one for the last part of an environment option and one for the other parts. Make sure you cover both; this was the biggest problem with the sample patch I first distributed. * If it is possible to stuff a string into the environment twice with your telnetd, make sure you check all entries in the environment. For example, if you have a setenv() that doesn't check for duplicates, don't just use unsetenv() as this will remove the last item in the environment, leaving the others to be used by login. Sample Patch Below, I include the official patch to telnet from David Borman as of October 23. Before the patch, I include a message I received on October 19; this includes useful information. As I received the message, it was not PGP-signed; its inclusion in this signed summary indicates that it has not been modified since I received it, and says nothing about the integrity of the communications link between myself and Mr. Borman. However, I have examined the patch, and it appears to be a valid fix for the bug. It also corresponds to the appropriate sections of the diff on the ftp server. Again, patches are provided as-is without a guarantee of correctness; you assume all risk for applying this patch. (As with all PGP-signed patches, you will need to remove leading dashes.) Date: Thu, 19 Oct 95 13:54:56 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9510191854.AA03474@frenzy.cray.com> To: hartmans@MIT.EDU Subject: Re: telnet vulnerability giving root access Cc: cert@cert.org, tytso@MIT.EDU I have placed a version of the BSD Telnet distribution at: ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z with a fix for this problem. It changes telnetd to remove the LD_*, _RLD_*, IFS and LIBPATH environment variables before execing login. The version on ftp.cray.com does not contain the encryption code, that is on net-dist.mit.edu, and I have sent a new copy off to them to replace the current distribution. (The attached diffs also show a bugfix for a problem that was screwing up /etc/utmp on Solaris.) Also, BSDI is not affected, as they do not provide any way for the user to override the search path for shared libraries. UNICOS is unaffected, since we don't have shared libraries. Please feel free to pass on this message. -David Borman, dab@cray.com diff -cbr telnet.95.05.31/telnetd/sys_term.c telnet.95.10.23/telnetd/sys_term.c *** telnet.95.05.31/telnetd/sys_term.c Wed May 31 00:50:57 1995 - --- telnet.95.10.23/telnetd/sys_term.c Mon Oct 23 09:47:17 1995 *************** *** 32,38 **** */ #ifndef lint ! static char sccsid[] = "@(#)sys_term.c 8.4 (Berkeley) 5/30/95"; #endif /* not lint */ #include "telnetd.h" - --- 32,38 ---- */ #ifndef lint ! static char sccsid[] = "@(#)sys_term.c 8.4+1 (Berkeley) 5/30/95"; #endif /* not lint */ #include "telnetd.h" *************** *** 1570,1579 **** utmpx.ut_id[3] = SC_WILDC; utmpx.ut_type = LOGIN_PROCESS; (void) time(&utmpx.ut_tv.tv_sec); ! if (pututxline(&utmpx) == NULL) ! fatal(net, "pututxline failed"); #endif /* * -h : pass on name of host. * WARNING: -h is accepted by login if and only if - --- 1570,1581 ---- utmpx.ut_id[3] = SC_WILDC; utmpx.ut_type = LOGIN_PROCESS; (void) time(&utmpx.ut_tv.tv_sec); ! if (makeutx(&utmpx) == NULL) ! fatal(net, "makeutx failed"); #endif + scrub_env(); + /* * -h : pass on name of host. * WARNING: -h is accepted by login if and only if *************** *** 1809,1814 **** - --- 1811,1836 ---- return(argv); } #endif /* NEWINIT */ + + /* + * scrub_env() + * + * Remove a few things from the environment that + * don't need to be there. + */ + scrub_env() + { + register char **cpp, **cpp2; + + for (cpp2 = cpp = environ; *cpp; cpp++) { + if (strncmp(*cpp, "LD_", 3) && + strncmp(*cpp, "_RLD_", 5) && + strncmp(*cpp, "LIBPATH=", 8) && + strncmp(*cpp, "IFS=", 4)) + *cpp2++ = *cpp; + } + *cpp2 = 0; + } /* * cleanup() Acknowledgments In preparing this bug summary, I have received the help of several people. In particular, I would like to thank David Borman for quickly fixing the problem once notified, and Bruce Lewis for supplying a timely solution to the problem within MIT. In addition, John Hawkinson provided help developing exploit scripts and confirming that the bug existed on several systems. I would also like to thiank those at MIT who reviewed drafts of this announcement and suggested improvements. - - -- Sam Hartman, MIT Kerberos Development team -----BEGIN PGP SIGNATURE----- Version: 2.6.2 iQEUAwUBMIyQAEJYVPVo3rXRAQE4Lwf46xcucSdiA/uKBOfEIAZM394nIJ6mcYCD gQb7Le+R6Tx9dFYU7rbAvsaoxaeh70ikAXpl0U+wE8kV86u8NuM7RXPkLrwWJWPt Po2EjrPGneLvxBovAReZPUEZQxRbFvOWKU4tXSPsQJpAY3o6p4sRAG4d3hMal9KP miD5RB65ow8dq46n+VA+t1O4BfuiMkdTwToEt3tMV7dCTJCydZkMg0ZUmg6q6MeB BoXxMELmVJXxof2pmpg4bw1yWkoX1oWvdFJu2qpAF/oC/jY5f4VbtDnorEVpjgVz UMqQIcYpESisGuGk0xvJtPdo7ZPUXWgvk//Vo3sNnpMKvl2CTuH+ =CWs7 -----END PGP SIGNATURE----- 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 From owner-freebsd-security Tue Oct 24 07:29:09 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id HAA14523 for security-outgoing; Tue, 24 Oct 1995 07:29:09 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id HAA14518 for ; Tue, 24 Oct 1995 07:29:05 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t7kLY-0003yeC; Tue, 24 Oct 95 07:28 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id PAA02240; Tue, 24 Oct 1995 15:28:50 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: dab@cray.com, security@freebsd.org, hartmans@mit.edu Subject: Re: telnetd fix In-reply-to: Your message of "Tue, 24 Oct 1995 07:07:43 MST." <199510241407.HAA27483@corbin.Root.COM> Date: Tue, 24 Oct 1995 15:28:50 +0100 Message-ID: <2238.814544930@critter.tfs.com> From: Poul-Henning Kamp 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 t he > 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 thos e > two comprise a complete list - I can't think of any legitimate others). [...] Could I suggest that we add /etc/default/telnetd and that it can contain a list of allowed environment variables ? -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Tue Oct 24 08:23:31 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA17411 for security-outgoing; Tue, 24 Oct 1995 08:23:31 -0700 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA17401 for ; Tue, 24 Oct 1995 08:23:26 -0700 Received: from frenzy.cray.com (frenzy.cray.com [128.162.84.21]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id KAA26366 for ; Tue, 24 Oct 1995 10:23:23 -0500 Received: by frenzy.cray.com id AA05306; 4.1/CRI-5.6; Tue, 24 Oct 95 10:23:48 CDT Date: Tue, 24 Oct 95 10:23:48 CDT From: dab@berserkly.cray.com (David A. Borman) Message-Id: <9510241523.AA05306@frenzy.cray.com> To: davidg@Root.COM Subject: Re: telnetd fix Cc: hartmans@mit.edu, security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk > 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: ... > 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. It's not that simple. The whole point of the environment option is to allow the passing of arbitrary environment variables, because you don't know what poeple may want to pass through. Changing telnetd to only allow an enumerated list of variables through means that if I have some private application that looks at an environement variable, and I want to propogate that variable, I then have to go to the administrator and ask that my personal variable be added to the list. Depending on the system/administrator, that can be a hassel and take time, and I'd probably just go back to setting things up in a .profile or .cshrc through some home-brew out-of-band mechanism, defeating the whole purpose of having the environ option in telnet. The fact of the matter is that what telnetd really wants to do is to put things into the users environment, not the environment of login. However the only current mechanism for doing that is to put things into the environment of login, which then passes them on to the login shell. The current fix does the minimal amount of work needed to solve the immediate problem, and a better long-term solution can be developed without the pressure of getting out a fix ASAP. -David Borman, dab@cray.com From owner-freebsd-security Tue Oct 24 08:51:58 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA18524 for security-outgoing; Tue, 24 Oct 1995 08:51:58 -0700 Received: from vhf.dataradio.com (G496.InterLink.NET [198.168.61.62]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA18517 for ; Tue, 24 Oct 1995 08:51:50 -0700 Received: (from root@localhost) by vhf.dataradio.com (8.6.9/8.6.12) id LAA28650; Tue, 24 Oct 1995 11:51:28 -0400 Date: Tue, 24 Oct 1995 11:51:27 -0400 (EDT) From: Dataradio sysadmin To: "David A. Borman" cc: davidg@Root.COM, hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix In-Reply-To: <9510241523.AA05306@frenzy.cray.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk On Tue, 24 Oct 1995, David A. Borman wrote: > > > 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 [snip] Have I missed something here? Why not just compile telnetd / login as a statically linked programs, and voila, no worry about possibly switching libc under their noses. ----- Andrew Webster DATARADIO, Inc. Network Manager http://www.dataradio.com Special Projects awebster@dataradio.com From owner-freebsd-security Tue Oct 24 09:38:12 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id JAA20361 for security-outgoing; Tue, 24 Oct 1995 09:38:12 -0700 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id JAA20356 for ; Tue, 24 Oct 1995 09:38:07 -0700 Received: from berserkly.cray.com (berserkly.cray.com [128.162.96.70]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id LAA11111 for ; Tue, 24 Oct 1995 11:38:04 -0500 Received: by berserkly.cray.com id AA00953; 5.64/CRI-4.9; Tue, 24 Oct 95 11:35:17 -0500 Date: Tue, 24 Oct 95 11:35:17 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9510241635.AA00953@berserkly.cray.com> To: dab@berserkly.cray.com, root@vhf.dataradio.com Subject: Re: telnetd fix Cc: davidg@Root.COM, hartmans@mit.edu, security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk > Have I missed something here? > > Why not just compile telnetd / login as a statically linked programs, and > voila, no worry about possibly switching libc under their noses. > > ----- > Andrew Webster DATARADIO, Inc. > Network Manager http://www.dataradio.com > Special Projects awebster@dataradio.com You are assuming you have the source to recompile/relink login. -David Borman, dab@cray.com From owner-freebsd-security Tue Oct 24 15:42:35 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id PAA08759 for security-outgoing; Tue, 24 Oct 1995 15:42:35 -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 PAA08748 for ; Tue, 24 Oct 1995 15:42:29 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id PAA06756; Tue, 24 Oct 1995 15:42:26 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id PAA27570; Tue, 24 Oct 1995 15:38:23 -0700 Message-Id: <199510242238.PAA27570@corbin.Root.COM> To: Dataradio sysadmin cc: "David A. Borman" , hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix In-reply-to: Your message of "Tue, 24 Oct 95 11:51:27 EDT." From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 15:38:17 -0700 Sender: owner-security@freebsd.org Precedence: bulk >On Tue, 24 Oct 1995, David A. Borman wrote: > >> >> > 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 > >[snip] > >Have I missed something here? > >Why not just compile telnetd / login as a statically linked programs, and >voila, no worry about possibly switching libc under their noses. Because the standard libc in most systems also access certain environment variables that may be used to alter the behavior of telnetd and/or login(1). In other words: the list of vulnerable systems is likely much longer than is suggested in the announcement. -DG From owner-freebsd-security Tue Oct 24 16:05:23 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id QAA10430 for security-outgoing; Tue, 24 Oct 1995 16:05:23 -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 QAA10425 for ; Tue, 24 Oct 1995 16:05:18 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id QAA06820; Tue, 24 Oct 1995 16:05:15 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id QAA27606; Tue, 24 Oct 1995 16:01:09 -0700 Message-Id: <199510242301.QAA27606@corbin.Root.COM> To: dab@berserkly.cray.com (David A. Borman) cc: hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix In-reply-to: Your message of "Tue, 24 Oct 95 10:23:48 CDT." <9510241523.AA05306@frenzy.cray.com> From: David Greenman Reply-To: davidg@Root.COM Date: Tue, 24 Oct 1995 16:01:09 -0700 Sender: owner-security@freebsd.org Precedence: bulk >It's not that simple. The whole point of the environment option is >to allow the passing of arbitrary environment variables, because you >don't know what poeple may want to pass through. Changing telnetd to only >allow an enumerated list of variables through means that if I have some >private application that looks at an environement variable, and I want >to propogate that variable, I then have to go to the administrator and >ask that my personal variable be added to the list. What can I say? It's a feature that has serious security ramifications that likely can't be completely worked around in all cases. >The current fix does the minimal amount of work needed to solve the >immediate problem, and a better long-term solution can be developed >without the pressure of getting out a fix ASAP. I remain unconvinced that the list of envirnoment variables in the proposed patch is complete. After looking at the telnet manpage, I understand better the desire to keep the original functionality of being able to pass arbitrary variables, but honestly, I think this feature is only marginally useful for the generic case. Even in the case of DISPLAY, I have to add it to my standard .login because there are too many systems that I deal with that don't support telnet environment passing option. 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. -DG From owner-freebsd-security Wed Oct 25 02:03:23 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id CAA05177 for security-outgoing; Wed, 25 Oct 1995 02:03:23 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id CAA05159 for ; Wed, 25 Oct 1995 02:03:17 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t81jq-0003x4C; Wed, 25 Oct 95 02:03 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id KAA03163; Wed, 25 Oct 1995 10:03:07 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: davidg@Root.COM cc: dab@berserkly.cray.com (David A. Borman), hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix In-reply-to: Your message of "Tue, 24 Oct 1995 16:01:09 MST." <199510242301.QAA27606@corbin.Root.COM> Date: Wed, 25 Oct 1995 10:03:07 +0100 Message-ID: <3161.814611787@critter.tfs.com> From: Poul-Henning Kamp 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. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. From owner-freebsd-security Wed Oct 25 08:03:43 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA18059 for security-outgoing; Wed, 25 Oct 1995 08:03:43 -0700 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA18050 for ; Wed, 25 Oct 1995 08:03:38 -0700 Received: from berserkly.cray.com (berserkly.cray.com [128.162.96.70]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id KAA22331 for ; Wed, 25 Oct 1995 10:03:36 -0500 Received: by berserkly.cray.com id AA00695; 5.64/CRI-4.9; Wed, 25 Oct 95 10:00:43 -0500 Date: Wed, 25 Oct 95 10:00:43 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9510251500.AA00695@berserkly.cray.com> To: davidg@Root.COM Subject: Re: telnetd fix Cc: hartmans@mit.edu, security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk > From root@corbin.Root.COM Tue Oct 24 18:02:46 1995 > To: dab@berserkly.cray.com (David A. Borman) > Cc: hartmans@mit.edu, security@freebsd.org > Subject: Re: telnetd fix > From: David Greenman > Reply-To: davidg@Root.COM > Date: Tue, 24 Oct 1995 16:01:09 -0700 > > >It's not that simple. The whole point of the environment option is > >to allow the passing of arbitrary environment variables, because you > >don't know what poeple may want to pass through. Changing telnetd to only > >allow an enumerated list of variables through means that if I have some > >private application that looks at an environement variable, and I want > >to propogate that variable, I then have to go to the administrator and > >ask that my personal variable be added to the list. > > What can I say? It's a feature that has serious security ramifications that > likely can't be completely worked around in all cases. > > >The current fix does the minimal amount of work needed to solve the > >immediate problem, and a better long-term solution can be developed > >without the pressure of getting out a fix ASAP. > > I remain unconvinced that the list of envirnoment variables in the proposed > patch is complete. After looking at the telnet manpage, I understand better > the desire to keep the original functionality of being able to pass arbitrary > variables, but honestly, I think this feature is only marginally useful for the > generic case. Even in the case of DISPLAY, I have to add it to my standard > .login because there are too many systems that I deal with that don't support > telnet environment passing option. > 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. > > -DG I am currently testing new code in telnetd that will allow: 1) Only a specific list of "safe" variables will go directly into the environment. 2) All other variables are encoded in such a way to be "safe"; however after the user has logged in they will need to run a program to make those environment variables accessable. 3) Provide a configuration file for telnetd to custom tailor the "safe" variable list, along with other configuration information. Be patient, the quick patches solve the immediate problem, and provide a little breathing room for working out a much better long term solution to the problem. I'll provide more details once I actually have working code. -David Borman, dab@cray.com From owner-freebsd-security Wed Oct 25 20:03:45 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id UAA21150 for security-outgoing; Wed, 25 Oct 1995 20:03:45 -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 UAA21123 for ; Wed, 25 Oct 1995 20:03:34 -0700 Received: from corbin.Root.COM (corbin [198.145.90.50]) by Root.COM (8.6.12/8.6.5) with ESMTP id UAA09108; Wed, 25 Oct 1995 20:03:31 -0700 Received: from localhost (localhost [127.0.0.1]) by corbin.Root.COM (8.6.12/8.6.5) with SMTP id TAA02836; Wed, 25 Oct 1995 19:55:45 -0700 Message-Id: <199510260255.TAA02836@corbin.Root.COM> To: Michael Smith cc: dab@berserkly.cray.com (David Borman), hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix In-reply-to: Your message of "Thu, 26 Oct 95 12:02:58 +0930." <199510260232.MAA09332@genesis.atrad.adelaide.edu.au> From: David Greenman Reply-To: davidg@Root.COM Date: Wed, 25 Oct 1995 19:55:45 -0700 Sender: owner-security@freebsd.org Precedence: bulk >> 3) Provide a configuration file for telnetd to >> custom tailor the "safe" variable list, along >> with other configuration information. > >But aren't you addressing the _wrong_ side of the problem? It's not >random environment variables that are the danger, but a _specific_ (small) >set. Why not provide a customisable list of variables that are _not_ >permitted? This avoids all of the encoding/decoding cruft, and achieves >that same goal, does it not? The list for exclusion is long and almost guaranteed to be incomplete. It seems to keep growing daily. -DG From owner-freebsd-security Thu Oct 26 03:42:44 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA00797 for security-outgoing; Thu, 26 Oct 1995 03:42:44 -0700 Received: from racer.dkrz.de (racer.dkrz.de [136.172.110.55]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id DAA00787 for ; Thu, 26 Oct 1995 03:42:31 -0700 Received: from madonna.dkrz.de.dkrz.de (madonna.dkrz.de [136.172.110.69]) by racer.dkrz.de (8.7.1/8.7.1) with SMTP id LAA16603; Thu, 26 Oct 1995 11:40:08 +0100 (MET) Date: Thu, 26 Oct 1995 11:40:08 +0100 (MET) From: "Georg-W. Koltermann" Message-Id: <199510261040.LAA16603@racer.dkrz.de> Received: by madonna.dkrz.de.dkrz.de (4.1/SMI-4.1) id AA04223; Thu, 26 Oct 95 11:40:49 +0100 To: phk@critter.tfs.com Cc: davidg@Root.COM, dab@berserkly.cray.com, hartmans@mit.edu, security@freebsd.org In-Reply-To: <3161.814611787@critter.tfs.com> (message from Poul-Henning Kamp on Wed, 25 Oct 1995 10:03:07 +0100) Subject: Re: telnetd fix Reply-To: gwk@cray.com Sender: owner-security@freebsd.org Precedence: bulk > X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol > cc: dab@berserkly.cray.com (David A. Borman), hartmans@mit.edu, > security@freebsd.org > Date: Wed, 25 Oct 1995 10:03:07 +0100 > From: Poul-Henning Kamp > 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. Regards, Georg-W. Koltermann, gwk@cray.com From owner-freebsd-security Thu Oct 26 03:55:55 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id DAA01356 for security-outgoing; Thu, 26 Oct 1995 03:55:55 -0700 Received: from tfs.com (tfs.com [140.145.250.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id DAA01349 for ; Thu, 26 Oct 1995 03:55:49 -0700 Received: from critter.tfs.com by tfs.com (smail3.1.28.1) with SMTP id m0t8PyD-0003wsC; Thu, 26 Oct 95 03:55 PDT Received: from localhost (localhost [127.0.0.1]) by critter.tfs.com (8.6.11/8.6.9) with SMTP id LAA01040; Thu, 26 Oct 1995 11:55:34 +0100 X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO protocol To: gwk@cray.com cc: davidg@Root.COM, dab@berserkly.cray.com, hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix In-reply-to: Your message of "Thu, 26 Oct 1995 11:40:08 +0100." <199510261040.LAA16603@racer.dkrz.de> Date: Thu, 26 Oct 1995 11:55:34 +0100 Message-ID: <1038.814704934@critter.tfs.com> From: Poul-Henning Kamp Sender: owner-security@freebsd.org Precedence: bulk > > X-Authentication-Warning: critter.tfs.com: Host localhost didn't use HELO p rotocol > > cc: dab@berserkly.cray.com (David A. Borman), hartmans@mit.edu, > > security@freebsd.org > > Date: Wed, 25 Oct 1995 10:03:07 +0100 > > From: Poul-Henning Kamp > > Sender: owner-security@freebsd.org > > Precedence: bulk > > > > > At the moment, I'm seriously considering adding a switch to shut off t he > > > 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. Well, we rely on login being able to find one of two different libcrypt to handle the DES versus MD5 encryption... So, nice idea, bad idea... -- Poul-Henning Kamp | phk@FreeBSD.ORG FreeBSD Core-team. http://www.freebsd.org/~phk | phk@login.dknet.dk Private mailbox. whois: [PHK] | phk@ref.tfs.com TRW Financial Systems, Inc. Future will arrive by its own means, progress not so. 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 From owner-freebsd-security Thu Oct 26 05:27:11 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id FAA04215 for security-outgoing; Thu, 26 Oct 1995 05:27:11 -0700 Received: from fledge.watson.org (FLEDGE.RES.CMU.EDU [128.2.95.74]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id FAA04210 for ; Thu, 26 Oct 1995 05:27:09 -0700 Received: (from robert@localhost) by fledge.watson.org (8.6.11/8.6.10) id IAA09174; Thu, 26 Oct 1995 08:27:03 -0400 Date: Thu, 26 Oct 1995 08:27:02 -0400 (EDT) From: Robert Watson To: David Greenman cc: gwk@cray.com, phk@critter.tfs.com, dab@berserkly.cray.com, hartmans@mit.edu, security@freebsd.org Subject: Re: telnetd fix In-Reply-To: <199510261200.FAA00275@corbin.Root.COM> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-security@freebsd.org Precedence: bulk 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 > 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 From owner-freebsd-security Thu Oct 26 08:46:30 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10507 for security-outgoing; Thu, 26 Oct 1995 08:46:30 -0700 Received: from timbuk.cray.com (root@timbuk.cray.com [128.162.19.7]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA10491 for ; Thu, 26 Oct 1995 08:46:24 -0700 Received: from berserkly.cray.com (berserkly.cray.com [128.162.96.70]) by timbuk.cray.com (8.6.12/CRI-gate-8-2.11) with SMTP id KAA02571 for ; Thu, 26 Oct 1995 10:46:21 -0500 Received: by berserkly.cray.com id AA01399; 5.64/CRI-4.9; Thu, 26 Oct 95 10:43:21 -0500 Date: Thu, 26 Oct 95 10:43:21 -0500 From: dab@berserkly.cray.com (David Borman) Message-Id: <9510261543.AA01399@berserkly.cray.com> To: davidg@Root.COM Subject: Re: telnetd fix Cc: hartmans@mit.edu, security@freebsd.org Sender: owner-security@freebsd.org Precedence: bulk The code I am working on for telnetd will provide the system administrator with the maximum amount of flexability in dealing with the environment option. You can make things as restrictive or as liberal as you want. You can let everything throug verbatim, you can encode everthing, you can remove/igonre some, you can do a combination, you can ignore everything. -David Borman, dab@cray.com From owner-freebsd-security Thu Oct 26 08:53:00 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id IAA10970 for security-outgoing; Thu, 26 Oct 1995 08:53:00 -0700 Received: from racer.dkrz.de (racer.dkrz.de [136.172.110.55]) by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA10955 for ; Thu, 26 Oct 1995 08:52:54 -0700 Received: from madonna.dkrz.de.dkrz.de (madonna.dkrz.de [136.172.110.69]) by racer.dkrz.de (8.7.1/8.7.1) with SMTP id QAA16944; Thu, 26 Oct 1995 16:50:40 +0100 (MET) Date: Thu, 26 Oct 1995 16:50:40 +0100 (MET) From: "Georg-W. Koltermann" Message-Id: <199510261550.QAA16944@racer.dkrz.de> Received: by madonna.dkrz.de.dkrz.de (4.1/SMI-4.1) id AA04333; Thu, 26 Oct 95 16:51:22 +0100 To: davidg@Root.COM Cc: phk@critter.tfs.com, dab@berserkly.cray.com, hartmans@mit.edu, security@freebsd.org In-Reply-To: <199510261200.FAA00275@corbin.Root.COM> (message from David Greenman on Thu, 26 Oct 1995 05:00:19 -0700) Subject: Re: telnetd fix Reply-To: gwk@cray.com 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 David, [[ well, maybe I was not listening close enough, I will not deny that I am unable to read every line of every mail carefully when I receive so many of them every day.]] In my opinion these other environment variables *should not* be a problem. Or at least not a problem that can be fixed in telnetd. A program that runs with root priviledges on behalf of a user *has to* take special precaution that it is side-effect free. For example, it must not use $PATH, nor $HOME without checking carefully if these are trouble-free. It must not use any inherited environment variable as part of the name of a file that it writes without similar security measures. Of course the same care has to be applied with regard to any library routine that is called which in turn can use environment variables. After all nothing prevents any user from setting up a malicious environment and then typing /usr/bin/login! I believe these issues are understood and taken care of by people who write these kinds of programs. On the other hand, no programmer can safeguard against linking in code from a bad dynamic library long after he has finished his program. So extra steps must be taken that a program with root priviledges actually uses only the code that the programmer wanted. One approach is having ld.so effectively ignore environment variables like $LD_LIBRARY_PATH. The SUNOS man page for ld.so says, e. g.: NOTE: when running a set-user- or set-group-ID program, ld.so will only search for libraries in directories it "trusts", which are /usr/lib, /usr/5lib, /usr/local/lib, and any directories specified within the executable as a result of -L options given when the executable was constructed. A previous mail from Sam Hartman included a more detailed explanation (maybe that part was contributed by Theodore Ts'o): Most runtime linkers treat set user-id and set group-id programs specially: for these programs the environment variables are ignored when the program is run by a user other than the owner of the file, or by someone in a group other than the primary group of the file. Even though login is often set user-id, the environment variables are used because it is run by telnetd which runs as root. So it seems the action taken in ld.so is only effective if login gets called by a logged-in user, and not when it gets started by telnetd or any other root-process (xdm? rlogind? you-name-it-d?). The next logical step would be to avoid dynamic linking altogether for the login program. This has been proposed by someone else before (I don't recall his name), and I brought it up again in my previous mail. There remains an issue with static linking. Sometimes library writers invent new features. Functions which previously were simple and safe later become feature-full and tailorable by environment variables. E. g. some versions of tmpfile(3) obey $TMPDIR if set, while older versions use the hard-coded P_tmpdir from for the directory where the file is created. This way a program which was believed-safe may become unsafe just by relinking with a newer version of a library routine. This is in no way restricted to dynamic linking, it can happen just as well with static linking at compile time. The *only* protection here is, IMHO, to have the program *itself* clear out the environment at startup time. One can *not* depend on the caller (which happens to be telnetd here) to do this, because in almost every case the caller could just as well be a shell operated by a malicious user. $DISCLAIMER (you know what I mean) Georg-W. Koltermann, gwk@cray.com From owner-freebsd-security Thu Oct 26 14:52:25 1995 Return-Path: owner-security Received: (from root@localhost) by freefall.freebsd.org (8.6.12/8.6.6) id OAA28832 for security-outgoing; Thu, 26 Oct 1995 14:52:25 -0700 Received: from jli (jli.portland.or.us [199.2.111.1]) by freefall.freebsd.org (8.6.12/8.6.6) with SMTP id OAA28812 for ; Thu, 26 Oct 1995 14:52:20 -0700 Received: from cumulus by jli with uucp (Smail3.1.29.1 #3) id m0t8aD7-0001b9C; Thu, 26 Oct 95 14:51 PDT Message-Id: X-Wily-Tags: Put then wsend To: gwk@cray.com, davidg@Root.COM Cc: phk@critter.tfs.com, dab@berserkly.cray.com, hartmans@mit.edu, security@FreeBSD.ORG Subject: Re: telnetd fix References: <199510261550.QAA16944@racer.dkrz.de> In-reply-to: Your message of Thu, 26 Oct 1995 16:50:40 BST. <199510261550.QAA16944@racer.dkrz.de> Date: Thu, 26 Oct 1995 14:51:15 -0700 From: Bill Trost Sender: owner-security@FreeBSD.ORG Precedence: bulk I would like to propose a solution substantially different from the one seemingly everyone else has been exploring. I havve discussed this in a similar context -- let's see what's wrong with it here. (-: The problem is not that telnetd can pass along "bad" environment variables, but that telnetd is a program *running as root* that can pass along bad environment variables. The question then becomes: Why does telnetd need to run as root? As far as I can tell, telnetd is run as root so that it can modify /var/run/utmp, either directly or via the -h flag to login. The solution I propose, then, is to create a new user (say, "utmp") that owns (or can at least write) the utmp file. Telnetd runs as this user, so it can clear out the utmp entry when the child's session has closed. /usr/bin/login doesn't check to see that it is running as root when given the -h flag; instead, it checks to see that the user that invoked it has write permissions on the utmp. Environment variables passed in by telnetd then become handled the same way they do when passed in from a user's shell, which takes care of the shared library problem. This solution could close some unknown holes in telnetd as well -- the next stack-spamming attack, for instance.