Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (Generic)  >   Telnet Vendors:   [Multiple Authors/Vendors]
(Slackware Issues Fix) Re: Telnet Daemons May Give Remote Users Root Level Access Privileges
SecurityTracker Alert ID:  1002284
SecurityTracker URL:
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Aug 27 2001
Impact:   Execution of arbitrary code via network, Root access via network, User access via network
Fix Available:  Yes  Vendor Confirmed:  Yes  

Description:   TESO reported that many BSD-derived Telnet daemons (servers) contain a vulnerability that may allow a remote user to obtain root level access on the server.

The vulnerability is reportedly due to a buffer overflow in the telnet option handling.

The following systems are reported to be vulnerable:

BSDI 4.x default, FreeBSD [2345].x default, IRIX 6.5, Linux netkit-telnetd < 0.14, NetBSD 1.x default, OpenBSD 2.x, Solaris 2.x sparc, and "almost any other vendor's telnetd".

A remote user can send a specially formatted option string to the remote telnet server and overwrite sensitive memory, causing arbitrary code to be executed with the privileges of the telnet server (which is typically root level privileges).

Telnet options are reportedly processed by the 'telrcv' function. The results of the parsing, which are to be send back to the client, are stored in the 'netobuf' buffer. It is apparently assumed that the reply data is smaller than the buffer size, so no bounds checking is performed. By using a combination of options, especially the 'AYT' Are You There option, it is possible for a remote user to append data to the buffer. It is reported that the characters that can be written to the buffer are limited, which makes constructing a successful exploit difficult.

The report states that a working exploit has been developed for BSDI, NetBSD and FreeBSD. However, the exploit was not released.

Impact:   A remote user can execute arbitrary code on the server with the privileges of the telnet server, which is typically root level privileges.
Solution:   Slackware has issued a fix. See the Source Message.
Cause:   Boundary error
Underlying OS:  Linux (Slackware)
Underlying OS Comments:  many Linux and Unix OSs are vulnerable, but not all - see the Alert text for more information

Message History:   This archive entry is a follow-up to the message listed below.
Jul 18 2001 Telnet Daemons May Give Remote Users Root Level Access Privileges

 Source Message Contents

Subject:  [slackware-security] netkit-telnet buffer overflow patched

An exploitable overflow has been found in the telnetd daemon contained in
Slackware's tcpip1 package.  More information about the problem may be
found here:

We urge all Slackware users to upgrade to a patched in.telnetd as soon as
possible.  Upgraded tcpip1.tgz packages as well as telnetd.tgz packages
containing only the fix have been prepared for Slackware 7.1 and 8.0.

Updated tcpip1 package for Slackware 8.0:

Updated tcpip1 package for Slackware 7.1:

Patch package (just in.telnetd) for Slackware 8.0:

Patch package (just in.telnetd) for Slackware 7.1:


Here are the md5sums for the packages:

Slackware 8.0:
bff3b57e4dc784f03d7af78df31d74f6  ./packages/tcpip1.tgz
b8956efcaaa0573be4bf7396e2976621  ./patches/telnetd.tgz

Slackware 7.1:
d0962b984fec93cf9fef0260538ed372  ./packages/tcpip1.tgz
d895b816b0d026367377e481e9ecfd46  ./packages/telnetd.tgz


It is recommended that the tcpip1 package be upgraded in single user
mode (runlevel 1).  Bring the system into runlevel 1:

   # telinit 1

Then upgrade the packages:

   # upgradepkg <package name>.tgz

Then bring the system back into multiuser mode:

   # telinit 3

The problem can also be patched using the telnetd.tgz patch package
instead.  Simply install as root:

   # installpkg telnetd.tgz

This will move the old in.telnetd out of the way and install the new one
to be used for subsequent connections.  Existing telnet connections will
not be interrupted.

Remember, it's also a good idea to backup configuration files before
upgrading packages.

- Slackware Linux Security Team


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, LLC