CERT Advisory CA-95:14 - Telnetd Environment Vulnerability
CERT Advisory
cert-advisory at cert.org
Wed Nov 1 23:10:09 UTC 1995
=============================================================================
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 at 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 at 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.
..............................................................................
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 at 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 <jkh at FreeBSD.org>
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" <tobias at et-inf.fho-emden.de>):
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.diff.gz
Red Hat Linux (From Erik Troan <ewt at redhat.com>):
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 <alan at cymru.net>):
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 <tytso at MIT.EDU> 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 at nec.co.jp
Open Software Foundation
------------------------
OSF/1 version 1.3 is not vulnerable.
OpenVision
----------
This is from: Barry Jaspan <bjaspan at cam.ov.com>:
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 at csd.sgi.com .
For reporting *NEW* SGI security issues, email can be sent to
security-alert at sgi.com.
Sony Corporation
----------------
Sony's NEWS-OS 6.x is not vulnerable.
..............................................................................
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 <stdio.h>
#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
More information about the NANOG
mailing list