Telnet Daemons May Give Remote Users Root Level Access Privileges
SecurityTracker Alert ID: 1002040|
SecurityTracker URL: http://securitytracker.com/id/1002040
(Links to External Site)
Updated: Sep 21 2004|
Original Entry Date: Jul 18 2001
Execution of arbitrary code via network, Root access via network, User access via network|
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 .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.
A remote user can execute arbitrary code on the server with the privileges of the telnet server, which is typically root level privileges.|
No solution was available at the time of this entry.|
|Underlying OS: Linux (Any), UNIX (Any)|
|Underlying OS Comments: many Linux and Unix OSs are vulnerable, but not all - see the Alert text for more information|
This archive entry has one or more follow-up message(s) listed below.|
Source Message Contents
Subject: telnetd vulnerability|
-----BEGIN PGP SIGNED MESSAGE-----
TESO Security Advisory
Multiple vendor Telnet Daemon vulnerability
Within most of the current telnet daemons in use today there exist a
overflow in the telnet option handling. Under certain circumstances
be possible to exploit it to gain root priviledges remotely.
System | vulnerable | exploitable
BSDI 4.x default | yes | yes
FreeBSD .x default | yes | yes
IRIX 6.5 | yes | no
Linux netkit-telnetd < 0.14 | yes | ?
Linux netkit-telnetd >= 0.14 | no |
NetBSD 1.x default | yes | yes
OpenBSD 2.x | yes | ?
OpenBSD current | no |
Solaris 2.x sparc | yes | ?
<almost any other vendor's telnetd> | yes | ?
* = From our analysis and conclusions, which may not be correct or
have overseen things. Do not rely on this.
Details about the systems can be found below.
Through sending a specially formed option string to the remote
daemon a remote attacker might be able to overwrite sensitive
on the static memory pages. If done properly this may result in
code getting executed on the remote machine under the priviledges
telnet daemon runs on, usually root.
Within every BSD derived telnet daemon under UNIX the telnet options
processed by the 'telrcv' function. This function parses the options
according to the telnet protocol and its internal state. During this
parsing the results which should be send back to the client are
within the 'netobuf' buffer. This is done without any bounds
since it is assumed that the reply data is smaller than the buffer
(which is BUFSIZ bytes, usually).
However, using a combination of options, especially the 'AYT' Are
option, it is possible to append data to the buffer, usually nine
long. To trigger this response, two bytes in the input buffer are
necessary. Since this input buffer is BUFSIZ bytes long, you can
output buffer by as much as (BUFSIZ / 2) * 9) - BUFSIZ bytes. For
common case that BUFSIZ is defined to be 1024, this results in a
overflow by up to 3584 bytes. On systems where BUFSIZ is defined to
4096, this is an even greater value (14336).
Due to the limited set of characters an attacker is able to write
of the buffer it is difficult - if not impossible on some systems -
exploit this buffer overflow. Another hurdle for a possible attacker
the lack of interesting information to modify after the buffer.
This buffer overflow should be considered serious nevertheless,
experience has shown that even complicated vulnerabilities can be
exploited by skilled attackers, BIND TSIG and SSH deattack come to
We have constructed a working exploit for any version of BSDI,
FreeBSD. Exploitation on Solaris sparc may be possible but if it is,
very difficult involving lots of arcane tricks. OpenBSD is not as
exploitable as the other BSD's, because they do compile with other
options by default, changing memory layout.
The vendors have been notified of the problem at the same time as
general public, vendor patches for your telnet daemon that fix the
show up soon.
Sometimes a fix might not be trivial and require a lot of changes to
source code, due to the insecure nature the 'nfrontp' pointer is
The best long term solution is to disable the telnet daemon at all,
there are good and free replacements.
The bug has been discovered by scut.
The tests and further analysis were done by smiler, lorian, zip and
The TESO crew can be reached by mailing to email@example.com
Our web page is at http://www.team-teso.net/
This advisory does not claim to be complete or to be usable for any
purpose. Especially information on the vulnerable systems may be
or wrong. Possibly supplied exploit code is not to be used for
purposes, but for educational purposes only.
This advisory is free for open distribution in unmodified form.
Articles that are based on information from this advisory should
Not this time. Not here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
-----END PGP SIGNATURE-----
Go to the Top of This SecurityTracker Archive Page