[30638] in Hotline Meeting
info: telnet vulnerability
daemon@ATHENA.MIT.EDU (Jerry Burke)
Tue Oct 31 15:52:53 1995
Date: Tue, 31 Oct 1995 15:51:48 -0500
To: hotline@MIT.EDU, dcns-support@MIT.EDU
From: burke@MIT.EDU (Jerry Burke)
>Date: Tue, 31 Oct 1995 15:44:12 -0500
>From: Sam Hartman <hartmans@MIT.EDU>
>To: netusers@MIT.EDU
>Reply-To: hartmans@MIT.EDU
>Subject: info: telnet vulnerability
>
>-----BEGIN PGP SIGNED MESSAGE-----
>
> So far, SGI hasn't actually released the patch, but I suspect
>that both SGI and DEC will make their patches available later today
>about the same time as the CERT advisory comes out.
>
> This memo presents information on a serious vulnerability in
>the telnet server for Unix workstations. It is divided into two
>sections: the first section answers common questions MIT users are
>likely to have about the problem, and tells how to obtain fixes to the
>problem within MIT. The second section is a fairly technical
>announcement of the details of the problem.
>
> This memo should answer most questions. However, several
>other sources of information exist if you have difficulty fixing the
>solution or need more information after reading the memo:
>
>* MIT students running Linux or NetBSD can call the Student
> Information Processing Board (SIPB) office at x3-7788 or send mail to
> the appropriate help list. Linux users should send mail to
> linux-help@mit.edu and NetBSD users should send mail to
> netbsd-help@mit.edu.
>
>* MIT faculty can contact David Lukas (dlukas@mit.edu) at x3-1459.
>
>* For other questions, Athena users can use the OLC service, call the
> Athena consulting office at x3-4435, or call the Network Help Desk
> at x3-4101.
>
>Q: What's the problem?
>
>A: There is a bug in Athena telnetd and the telnetd shipped with
> several operating systems. Telnetd is the program that allows
> users to telnet to private workstations and student computers
> running Linux or NetBSD. This bug allows intruders to trick the
> login process into running code they supply, breaking into the
> workstation as root.
>
>
>Q: Why is MIT particularly vulnerable to this problem?
>
>A: Many machines at MIT share files on AFS. Others, within labs,
> share files on NFS. Shared file spaces like AFS or NFS make it
> easier for attackers to gain access to the system, because it is
> easier for them to put the code they use to attack workstations in
> a place where the login process can find it. In addition,MIT
> encourages users to use the Athena telnet package, so secure,
> encrypted sessions can be established. This package is vulnerable
> for almost all platforms in common use at MIT.
>
>
>Q: Is my machine vulnerable?
>
>A: That depends; the only kind of machine in wide use at MIT that
> cannot be vulnerable to this attack at all is a DECstation running
> Ultrix. Other users should look at the following list and see if
> any of these apply to you.
>
> * If you installed telnet out of the telnet locker before Monday,
> October 30, you are vulnerable.
>
> * If you have an Athena workstation and have run `mkserv remote' or
> are using /etc/athena/telnetd, you are vulnerable.
>
> * If you have an SGI or a DEC Alpha, you're vulnerable, even if you
> are using the telnetd that came with the operating system. This
> is true if you can telnet to the machine and get a login prompt;
> you don't need to have an account on the machine.
>
> * If you have a Sun, running Sunos 4, and are running the telnetd
> that came with your operating system, you are not vulnerable.
>
> * If you are a student running Linux or NetBSD, you are probably
> vulnerable; you should upgrade.
>
> * If you have an HP workstation, you are not vulnerable.
>
>Q: How do I fix an Athena workstation or a workstation running Athena
> Telnet from the telnet locker?
>
>A: Athena Release Engineering has placed a fix for this problem on the
> Solaris system packs. Athena Suns running version 7.7U or later
> have a fixed telnetd. Users of other Athena workstations or
> non-Athena workstations using Athena's telnetd should update from
> the telnet locker. To do this, follow these steps:
>
> *Become root (your shell prompt will vary):
>
> bash$ su
> root's Password:
> bash#
>
> * Attach the telnet locker:
>
> bash# /bin/athena/attach -n telnet
> attach: /afs/athena.mit.edu/astaff/project/telnet linked to
> /mit/telnet for filesystem telnet
> bash#
>
> * Remove the old telnetd.
>
> bash# rm -f /etc/athena/telnetd
> bash#
>
> * Copy the appropriate telnetd into place from the telnet locker.
> You should choose the appropriate binary directory for your machine
> type: sun4bin for Suns, rsaixbin for RISC/6000s, alphabin for DEC
> Alphas, and arch/sgi_52/bin for SGIs. For example, I would replace
> /mit/telnet/rsaixbin/telnetd with /mit/telnet/sun4bin/telnetd if I
> were on a Sun instead of a RISC/6000.
>
> bash# cp -p /mit/telnet/rsaixbin/telnetd /etc/athena/telnetd
> bash#
>
>Q: How do I fix a PC running SIPB-Athena under Linux or NetBSD?
>
>A: Linux users should obtain a new version of the kerberos.tgz package
> from /mit/linux/packages after attaching the linux locker. Note
> that the version of kerberos.tgz released October 19 doesn't quite
> fix this problem completely, so if you upgraded in the last week or
> two, you should still upgrade again. In order to upgrade, execute
> the following commands as root:
>
> attach linux
> tar -xzvf /mit/linux/packages/kerberos.tgz -C /
>
> NetBSD users should execute the following two commands as root:
>
> rm -f /etc/athena/telnetd
> cp -p /srvd/etc/athena/telnetd /etc/athena/telnetd
>
>
>Q: What should users with private (non-Athena) workstations do to get a patch?
>
>A: It depends on the workstation. Look at the following list to see
> if we have dealt with your workstation yet. If not, consult the
> October 31 CERT advisory on this topic in the netusers discuss
> meeting.
>
>
> Sun: Sun workstations running Solaris or Sunos are not vulnerable
> if they are using the telnetd that came with the operating
> system. Unless you took special action to install the Athena
> telnet package, you are safe; if you took this action, please
> refer to the question about updating Athena telnetd.
>
> DECstations: DECstations are never vulnerable to this attack; there
> is no need to upgrade your telnetd because of this problem.
>
> HP Workstations: According to HP, their operating system is not
> vulnerable.
>
> IBM Risc/6000: The telnetd shipped with IBM's AIX operating system
> is safe. Unless action was taken to install Athena telnetd, the
> system is not vulnerable to this attack. If Athena telnetd was
> installed, it should be upgraded from the telnet locker.
>
>
> DEC alphas running Digital Unix or OSF 2.x: DEC has released a
> patch as of October 31; see the CERT advisory for information on
> how to obtain this patch. Alternatively, you can follow the
> instructions in /mit/telnet/README after attaching the telnet
> locker, and install Athena telnetd on your Alpha.
>
> SGI: SGI has released a patch to SGI telnet that can be obtained
> from ftp://sgigate.sgi.com/security/.
>
>Q: How should security compromises be reported?
>
>A: If you believe an intruder has compromised your system, using this
> or another hole, you can contact net-security@mit.edu; please be
> sure to include as much detail as you have so that the problem can
> be evaluated. Also, if you work in a lab or department where a
> person or group of people tends to run the computing facilities, you
> should let them know.
>
>
>
> Technical Info
>
> This memo contains a description of a vulnerability cause by
>an interaction between telnetd and shared library loaders on several
>versions of Unix. CERT should be issuing an advisory regarding this
>problem on October 31. While I have tried to keep an up to date list
>of available vendor patches in this memo, it is likely that the CERT
>advisory will contain more up-to-date vendor info. In particular, I
>don't have an exact URL to the FreeBSD, SGI or Digital Unix patch.This
>memo is intended to document the problem in MIT Kerberos and to
>provide additional detail that is likely not in the CERT advisory.
>
> Contents
>* Preface and History
>* Quick Fix
>* Environment Variables that Matter
>* Affected Telnetds
>* Telnetds that Work
>* Availability of Patches
>* Testing for Exposure
>* Verifying a Patch
>* Sample Patch
>* Acknowledgments
>
>
>
> Preface and History
>
> 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
>
> Normally, programs that run with the set-user-ID or
>set-group-ID bit set do not use environment variables to pass
>information about where to find libraries. This is designed to
>prevent attacks where an intruder sets LD_LIBRARY_PATH and runs `su'
>or `login' from the command line. Since these are set-user-ID
>programs, they run as root; if they trust LD_LIBRARY_PATH, then they
>can load a user-supplied libc and be as insecure as telnetd. The test
>used by most runtime linkers to determine if LD_LIBRARY_PATH can be
>trusted checks to see if the effective user ID is equal to the real
>user ID. Since telnet is started as a root-owned process by inetd,
>its real user ID is root. So, even if login is set-user-ID, the test
>succeeds and LD_LIBRARY_PATH is trusted, creating the security
>problem.
>
> On many systems, if login is made set-group-ID, the test will
>fail because login's effective group will be different than the real
>group. This should only be used on a temporary basis. Unfortunately,
>this doesn't always work: in particular, it doesn't work for SGI Irix.
>(SGI has already released a patch, but other systems may exist where
>this also fails.) If you try this fix, you should go through the
>"Testing for Exposure" section.
>
> To make login set-group-ID follow these steps:
>
>1) Create a new group (you might want to call it `__login',
> `__telnet', `tnbug' 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;change
> 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 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. According to the author of Linux
> ld.so (hjl@nynexst.com), this was only used by ld.so version 2.6.
> This version was only used for beta Elf development, and is
> apparently not used by any production Linux distributions.
>
>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. 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 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 OV*Secure contains a telnetd that is vulnerable; a
> patch is available.
>
>
> 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 (patch available)
>
>* Digital Unix. The telnetd distributed with stock Digital Unix
> appears to be vulnerable. DEC confirms they are investigating.
>
>* 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. A patch is also available for Redhat Linux.
>
>
> 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 <dab@cray.com> 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.
>
>* According to LaMont Jones <lamont@cranston.fc.hp.com>, "HP-UX is not
> vulnerable to this attack, due to our shared library
> implementation."
>
> 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
