MCI Data Systems Division internetMCI Security Group Incident Response Advisory Report Name: Telnetd Environment Vulnerability Report Number: iMCISE:MIIGS:CERT:1101:95:2ND Report Date: 11/01/95 Report Format: Summary Report Classification: MIIGS Report Distribution: On File ------------------------------------------------------------------------------- > >============================================================================= >CA-95:14 CERT Advisory > November 1, 1995 > Telnetd Environment Vulnerability >----------------------------------------------------------------------------- > >The CERT Coordination Center has been made aware of a vulnerability with >some telnet daemons. The daemons affected are those that support RFC 1408 >or RFC 1572, both titled "Telnet Environment Option," running on systems >that also support shared object libraries. > >To determine if your system is potentially vulnerable, refer to the >information we have received from vendors which is summarized in >Section III below; details are in Appendix A and reproduced in the >CA-95:14.README file. Note that if you installed a version of David >Borman's telnet package that is older than October 23, 1995, your >system may be vulnerable even though it was not vulnerable as distributed >by the vendor. > >If your vendor is not listed, you will need to determine if your system >may be vulnerable. First, determine if your telnet daemon is RFC 1408/1572 >compliant. One indication that it is compliant is if your telnet(1) >program supports the "environ" command or your telnetd(8) program supports >the ENVIRON or NEW-ENVIRON options. Unless you are certain that your >telnet daemon is not RFC 1408/1572 compliant, you may wish to assume it is >to be safe. Second, determine if your system supports shared libraries. To >do this, consult the ld(1) manual page. If it describes dynamic or shared >objects, your system probably supports shared object libraries. A system >is potentially vulnerable if the telnet daemon supports RFC 1408/RFC 1572 >and the system supports shared object libraries. > >We recommend that you follow your vendor's directions for addressing this >vulnerability. Until you can install a patch, we recommend using the >workaround in Appendix B below. If you have previously installed David >Borman's telnet package on your system, we recommend that you obtain the >current version of telnet (see Section III.C). > >As we receive additional information relating to this advisory, we will >place it in: > > ftp://info.cert.org/pub/cert_advisories/CA-95:14.README > >We encourage you to check our README files regularly for updates on >advisories that relate to your site. > >----------------------------------------------------------------------------- > >I. Description > > Some telnet daemons support RFC 1408 or RFC 1572, both titled "Telnet > Environment Option." This extension to telnet provides the ability > to transfer environment variables from one system to another. If > the remote or targeted system, the one to which the telnet is > connecting, is running an RFC 1408/RFC 1572-compliant telnet daemon > *and* the targeted system also supports shared object libraries, then > it may be possible to transfer environment variables that influence > the login program called by the telnet daemon. By influencing that > targeted system, a user may be able to bypass the normal login and > authentication scheme and may become root on that system. > > Users with accounts on the targeted system can exploit this > vulnerability. Users without accounts on that system can also > exploit this vulnerability if they are first able to deposit an > altered shared object library onto the targeted system. Therefore, a > system may be vulnerable to users with and without local accounts. > > Not all systems that run an RFC 1408/RFC 1572-compliant telnet daemon > and support shared object libraries are vulnerable. Some vendors have > changed the trust model such that environment variables provided by > the telnet daemon are not trusted and therefore are not used by the > login program. Section III contains a summary of information vendors > have reported as of the date of this advisory. > >II. Impact > > Local and remote users can become root on the targeted system. > >III. Solution > > The general solution to this problem is to replace the telnet daemon > with one that changes the environment given to the login program. We > recommend that you install a patch from your vendor if possible. If this > is not possible, we recommend using the workaround in Appendix B until > you can install a patch. Finally, if you have previously installed Mr. > Borman's telnet package, see Section C for how to get a new version that > fixes the vulnerability. > > A. Vendor Patches > > Below is a summary of the vendors listed in the current version of > the CA-95:14.README file, and the status they have provided. More > complete information, including how to obtain patches, is provided > in Appendix A of this advisory and reproduced in the README file. > We will update the README file as we receive more information from > vendors. > > If your vendor's name is not on this list, please contact the > vendor directly. > > REMINDER: If you installed a version of David Borman's telnet package > that is older than October 23, 1995, your system may be > vulnerable even though it was not vulnerable as distributed > by the vendor. > > Vendor or Source Status > ---------------- ------------ > Apple Computer not vulnerable > Berkeley Software Design not vulnerable > Cray Research not vulnerable > CYGNUS cns-95q1 - vulnerable > cns-95q4 - not vulnerable > Data General not vulnerable > Digital Equipment Ultrix - not vulnerable > OSF/1 - vulnerable > FreeBSD vulnerable > Harris not vulnerable > Hewlett-Packard not vulnerable > Linux Debian - vulnerable > Red Hat - vulnerable > Slackware - appears vulnerable > MIT-distributed for Athena vulnerable > NetBSD 1.0 - vulnerable > current - not vulnerable > NEC vulnerable > Open Software Foundation OSF/1 version 1.3 not vulnerable > OpenVision OpenV*Secure 1.2 - vulnerable > SCO not vulnerable > SGI 5.2, 5.3, 6.0.1, 6.1 - vulnerable > Sony Corp. NEWS-OS 6.x - not vulnerable > > B. Workaround > > Until you can install a patch from your vendor, you can use > the workaround provided in Appendix B. > > C. If you have installed a previous version of Mr. Borman's > telnet package, note that he has fixed this problem in > the version available at the following location: > > ftp://ftp.cray.com/src/telnet/telnet.95.10.23.NE.tar.Z > > MD5 checksum 2e14879a5b0aa6dd855a17fa8a3086cf > > >--------------------------------------------------------------------------- >The CERT Coordination Center staff thanks Eric Halil of AUSCERT, Wolfgang >Ley of DFNCERT, and Sam Hartman of the MIT Kerberos Development team for >their support in responding to this problem. >--------------------------------------------------------------------------- > >If you believe that your system has been compromised, contact the CERT >Coordination Center or your representative in the Forum of Incident >Response and Security Teams (FIRST). > >If you wish to send sensitive incident or vulnerability information to >CERT staff by electronic mail, we strongly advise that the email be >encrypted. The CERT Coordination Center can support a shared DES key, PGP >(public key available via anonymous FTP on info.cert.org), or PEM (contact >CERT staff for details). > >Internet email: cert@cert.org >Telephone: +1 412-268-7090 (24-hour hotline) > CERT personnel answer 8:30 a.m.-5:00 p.m. EST(GMT-5)/EDT(GMT-4), > and are on call for emergencies during other hours. >Fax: +1 412-268-6989 > >Postal address: CERT Coordination Center > Software Engineering Institute > Carnegie Mellon University > Pittsburgh, PA 15213-3890 > USA > >CERT advisories and bulletins are posted on the USENET newsgroup >comp.security.announce. If you would like to have future advisories and >bulletins mailed to you or to a mail exploder at your site, please send mail >to cert-advisory-request@cert.org. > >Past CERT publications, information about FIRST representatives, and >other information related to computer security are available for anonymous >FTP from info.cert.org. > > > >Copyright 1995 Carnegie Mellon University >This material may be reproduced and distributed without permission provided it >is used for non-commercial purposes and the copyright statement is included. > >CERT is a service mark of Carnegie Mellon University. > >^L >.............................................................................. >Appendix A: Vendor Information >Current as of November 1, 1995 >See CA-95.14.README for updated information > >Below is information we have received from vendors. If you do not see your >vendor's name below, contact the vendor directly for information. > >Apple Computer, Inc. >-------------------- >Apple's A/UX is not vulnerable. > >Berkeley Software Design, Inc. >----------------------------- >BSDI's BSD/OS is not vulnerable. > >Cray Research, Inc. >------------------- >Cray's UNICOS is not vulnerable. > >CYGNUS Network Security V4 Free Network Release >---------------------------------------------------- >cns-95q1 is vulnerable. cns-95q4 is not vulnerable. > >Customers can use the following URL to obtain the patch: > > http://www.cygnus.com/data/cns/telnetdpatch.html > >If customers are unable to obtain the patch in this manner >or have any questions, send e-mail to kerbask@cygnus.com/ > >Note that while the URL and patch are already available, there >is no link to the page yet. We will add a link once the >announcement has been made. > >Data General Corporation >------------------------ >Data General believes the DG/UX operating system to be >NOT vulnerable to this problem. This includes all supported >releases, DG/UX 5.4 Release 3.00, DG/UX 5.4 Release 3.10, >DG/UX Release 4.10 and all related Trusted DG/UX releases. > >Specifically, telnetd shipped in DG/UX does not support >environment options and does not support RFC 1572. > >Digital Equipment Corporation >----------------------------- >Digital's OSF/1: vulnerable >Digital's ULTRIX: not vulnerable > >Digital has corrected this potential vulnerability. Patches containing >new images for Digital's OSF/1 platforms are being provided to your >normal Digital Support channels beginning October 31 (U.S. time). The >kits may be identified as ECO SSRT0367 (telnetd) for DEC OSF/1 V2.0 >thru V3.2c > >This potential vulnerability is not present on Digital's ULTRIX systems. > >Digital distribution of this announcement will be via AES services (DIA, >DSNlink FLASH etc.). Digital Equipment Corporation strongly urges Customers >to upgrade to a minimum of DEC OSF/1 V3.0, then apply this patch. > >FreeBSD >------- >Vulnerable. A patch has been applied to the current development FreeBSD >source tree which is not yet released. This patch is slightly modified >compared to posted one, i.e. only variables which affects FreeBSD are >disabled. It is telnetd patch, not a login wrapper. > >For the official patch, location please contact: > >Jordan Hubbard > >Harris >------ >Harris Computer Systems Corporation's Night Hawk is not vulnerable. > >Hewlett-Packard Company >----------------------- >HP/UX is not vulnerable. > >Linux (freely available software; not a vendor) >----- >Debian GNU/Linux (From "Peter Tobias" ): >The current version of the Debian GNU/Linux distribution (released 10/27/95) >is not vulnerable anymore. All Debian Installations that use a netstd >package version prior to v1.21-1 are vulnerable (telnetd is part of >the netstd package). netstd-1.21-1 and above are ok. > >Patches are available. Peter fixed the bug last week and uploaded the >fixed version to our ftp site (ftp.debian.org). Binaries, sources and >the diffs against the bsd telnetd can be found there. The URL for the >new binary package is: > >ftp://ftp.debian.org/debian/debian-0.93/binary/net/netstd-1.21-1.deb > >and the sources and the diff against the bsd telnetd can be found at: > >ftp://ftp.debian.org/debian/debian-0.93/source/net/netstd-1.21-1/telnetd.tar.gz >ftp://ftp.debian.org/debian/debian-0.93/source/net/netstd-1.21-1/telnetd.di ff.gz > >Red Hat Linux (From Erik Troan ): >Vulnerable. A fix is now available at: > >ftp://ftp.redhat.com/pub/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm >ftp://ftp.pht.com/pub/linux/redhat/redhat-2.0/updates/NetKit-B-0.06-4.i386.rpm > >It will also be fixed in the upcoming Red Hat 2.1 release. > >Slackware Linux (Alan Cox ): >The telnetd distributed with Slackware Linux appears to be vulnerable, >although it has not been verified. > >MIT-distributed Athena telnet/telnet95 >-------------------------------------- >Vulnerable. Patches available in: > ftp://aeneas.mit.edu/pub/kerberos/telnet-patch/ > >beta4-3.patch is the patch versus the Beta 4 patchlevel 3 distribution >of Kerberos v5. > >beta5.patch is the patch versus the Beta 5 distribution of Kerberos V5. > >Both patches have been PGP signed by Ted Ts'o using >detached signatures (beta4-3.patch.sig and beta5.patch.sig). > >NetBSD >------ >NetBSD 1.0 (the last official release) is vulnerable; NetBSD 1.1 (due >out in mid-November) will not be. NetBSD-current is not vulnerable, >as of a week or so ago. > >Patches: A source form patch has been developed. A core team member will >have to make source and binary patches available and provide a location for >it. > >The login-wrapper given in the advisory can be compiled with NetBSD with: > cc -o login-wrapper login-wrapper.c > >NEC Corporation >--------------- >Some NEC systems are vulnerable. Here is their vulnerability matrix: > > OS Version Status >------------------ ------------ ------------------------------------- >EWS-UX/V(Rel4.0) R1.x - R6.x not vulnerable > >EWS-UX/V(Rel4.2) R7.x - R10.x not vulnerable > >EWS-UX/V(Rel4.2MP) R10.x vulnerable > patch available by the end of Nov, 1995 > >UP-UX/V R2.x - R4.x not vulnerable > >UP-UX/V(Rel4.2MP) R5.x - R7.x vulnerable > patch available by the end of Nov, 1995 > >UX/4800 R11.x vulnerable > patch available by the end of Nov, 1995 >-------------------------------------------------------------------------- >Contacts for further information: >E-mail:UX48-security-support@nec.co.jp > >Open Software Foundation >------------------------ >OSF/1 version 1.3 is not vulnerable. > >OpenVision >---------- >This is from: Barry Jaspan : >OpenVision has a patch for the telnetd in OpenV*Secure 1.2 and will >contact its customers directly. > >SCO >--- >Not believed to be vulnerable. > >Silicon Graphics >---------------- >IRIX 5.2, 5.3, 6.0.1, and 6.1 are vulnerable. > >SGI acknowledges the telnetd vulnerability reported by MIT and is >currently investigating. No further information is available at >this time. > >As further information becomes available, additional advisories will be >issued. > >SGI Security Information/Contacts: > >For obtaining security information, patches or assistance, please >contact your SGI support provider. > >If there are questions about this document, email can be sent to >cse-security-alert@csd.sgi.com . > >For reporting *NEW* SGI security issues, email can be sent to >security-alert@sgi.com. > >Sony Corporation >---------------- >Sony's NEWS-OS 6.x is not vulnerable. >^L >.............................................................................. >Appendix B: login-wrapper Workaround > >The login-wrapper program shown below is meant to be executed just before >the distributed login program. The wrapper cleans specific variables from >the environment before invoking the distributed login program. > >------------------------cut here--8<------------------------ >/* > * This is a login wrapper that removes all instances of > * various variables from the environment. > * > * Note: this program must be compiled statically to be > * effective against exploitation. > * > * Author: Lawrence R. Rogers > * > * 10/25/95 version 1.1 Original version > * 10/26/95 version 1.2 ELF_ variables removed (Linux) > * 10/27/95 version 1.3 ELF_ changed to ELF_LD_ > * Added AOUT_LD_ (Linux) > * > */ > >#include > >#if !defined(_PATH_LOGIN) ># define _PATH_LOGIN "/bin/login.real" >#endif > >main (argc, argv, envp) >int argc; >char **argv, **envp; >{ > register char **p1, **p2; > > for (p1 = p2 = envp; *p1; p1++) { > if (strncmp(*p1, "LD_", 3) != 0 && > strncmp(*p1, "_RLD", 4) != 0 && > strncmp(*p1, "LIBPATH=", 8) != 0 && > strncmp(*p1, "ELF_LD_", 7) != 0 && > strncmp(*p1, "AOUT_LD_", 8) != 0 && > strncmp(*p1, "IFS=", 4) != 0 ) { > *p2++ = *p1; > } > } > *p2 = 0; > execve(_PATH_LOGIN, argv, envp); > perror(_PATH_LOGIN); > exit(1); >} >------------------------cut here--8<------------------------ > >The following two examples show how to compile the login-wrapper for SGI's >IRIX 5.3 and FreeBSD 2.x systems. The examples move the distributed login >program to a new location and install the wrapper in the standard location. >When executed, the wrapper first cleanses the environment and then calls >the relocated, distributed login program. > >Note 1: The wrapper must be compiled statically. On SGI's IRIX system, >compiling statically requires that the non-shared versions of libraries >be installed. Consult your system documentation to determine how to do >this. > >Note 2: You may need to change the _PATH_LOGIN variable to define where >the real login program resides on your system. On some systems, login >resides in /usr/bin/login. > >Compiling for IRIX 5.3 >---------------------- ># uname -a >IRIX test 5.3 11091812 IP22 mips ># /bin/ls -lL /bin/login >-rwsr-xr-x 1 root sys 65832 Sep 9 14:24 /bin/login ># /bin/cc -non_shared -O login-wrapper.c -o login-wrapper ># /bin/mv /bin/login /bin/login.real ># /bin/chmod 755 /bin/login.real ># /bin/mv login-wrapper /bin/login ># /bin/chmod 4755 /bin/login ># /bin/chown root /bin/login ># /bin/chgrp sys /bin/login ># /bin/ls -lL /bin/login /bin/login.real >-rwxr-xr-x 1 root sys 65832 Sep 9 14:24 /bin/login.real >-rwsr-xr-x 1 root sys 213568 Oct 30 08:42 /bin/login > >Compiling for FreeBSD 2.x >------------------------- ># /bin/ls -lg /usr/bin/login >-r-sr-xr-x 1 root bin 20480 Jun 10 20:00 /usr/bin/login ># /usr/bin/cc -D_PATH_LOGIN=\"/usr/bin/login.real\" -static \ > -O login-wrapper.c -o login-wrapper ># /bin/mv /usr/bin/login /usr/bin/login.real ># /bin/chmod 555 /usr/bin/login.real ># /bin/mv login-wrapper /usr/bin/login ># /bin/chmod 4555 /usr/bin/login ># /usr/sbin/chown root.bin /usr/bin/login ># /bin/ls -lg /usr/bin/login /usr/bin/login.real >-r-sr-xr-x 1 root bin 24885 Oct 25 22:14 /usr/bin/login >-r-xr-xr-x 1 root bin 20480 Jun 10 20:00 /usr/bin/login.real > > "Success through teamwork" =============================================================================== Dale Drew MCI Telecommunications Manager internetMCI Security Engineering Voice: 703/715-7058 Internet: ddrew@mci.net Fax: 703/715-7066 MCIMAIL: Dale_Drew/644-3335