Subject: [Fwd: multiple vendor telnet daemon vulnerability]
To: None <email@example.com>
From: Emre Yildirim <emre@UNIX.US.EU.ORG>
Date: 07/18/2001 22:44:25
Content-Type: text/plain; charset=iso-8859-1
I got this today. It says a successful exploit has been tested with BSDI,
FreeBSD and NetBSD. Are there any patches out yet? Which versions of
NetBSD are vulnerable?
-------- Original Message --------
Subject: multiple vendor telnet daemon vulnerability
From: Sebastian <firstname.lastname@example.org>
This is a short version of the original advisory. Most details about
exploiting this vulnerabilty have been removed after thinking about it.
I do not release it because it makes me happy, and I would like you to
please not assume things about the reasons involving this posting. I wish
things would have worked out better for all of us. I do not want to get
that much involved into disclosure policies, but I am sure a lot of
advocates from both sides are going to flame me about this one. Please
save yourself and me the time, I could not care less.
A few days ago some script kiddies have somehow got access to a copy of
an exploit for this vulnerability. I do not know how it happened, but
while I write this dozen of BSD hosts fall victim to clueless attackers.
And please, again, I would like to ask you to not assume and speculate
how this might has happened.
The copy of the exploit was quite script-kiddie safe and requires no
fiddling. It works out of the box. Please patch fast, or better disable
telnetd at all.
Btw, I do not think a simple patch will do it anyway, there are so many
horrible bugs - also non security related - in telnetd beside this one.
Just send some random junk at telnetd and see it die if you do not
TESO Security Advisory
Multiple vendor Telnet Daemon vulnerability
================= Within most of the current telnet daemons in use
today there exist a buffer
overflow in the telnet option handling. Under certain circumstances
it may 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 we
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 telnet
daemon a remote attacker might be able to overwrite sensitive
information on the static memory pages. If done properly this may
result in arbitrary code getting executed on the remote machine under
the priviledges the telnet daemon runs on, usually root.
================= Within every BSD derived telnet daemon under UNIX
the telnet options are
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
stored within the 'netobuf' buffer. This is done without any bounds
checking, since it is assumed that the reply data is smaller than the
buffer size (which is BUFSIZ bytes, usually).
However, using a combination of options, especially the 'AYT' Are You
There option, it is possible to append data to the buffer, usually
nine bytes long. To trigger this response, two bytes in the input
buffer are necessary. Since this input buffer is BUFSIZ bytes long,
you can exceed the output buffer by as much as (BUFSIZ / 2) * 9) -
BUFSIZ bytes. For the common case that BUFSIZ is defined to be 1024,
this results in a buffer overflow by up to 3584 bytes. On systems
where BUFSIZ is defined to be 4096, this is an even greater value
Due to the limited set of characters an attacker is able to write
outside of the buffer it is difficult - if not impossible on some
systems - to exploit this buffer overflow. Another hurdle for a
possible attacker may be the lack of interesting information to
modify after the buffer.
This buffer overflow should be considered serious nevertheless, since
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, NetBSD
and FreeBSD. Exploitation on Solaris sparc may be possible but if it
is, it is very difficult involving lots of arcane tricks. OpenBSD is
not as easily 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 the
general public, vendor patches for your telnet daemon that fix the
bug will show up soon.
Sometimes a fix might not be trivial and require a lot of changes to
the source code, due to the insecure nature the 'nfrontp' pointer is
handled. The best long term solution is to disable the telnet daemon
at all, since there are good and free replacements.
================= The bug has been discovered by scut. (It is easy to
spot, so I do not
want to rule out discoveries by other persons)
The tests and further analysis were done by smiler, lorian, zip and
================= The TESO crew can be reached by mailing to
Our web page is at http://www.team-teso.net/
=================  TESO
================= This advisory does not claim to be complete or to be
usable for any
purpose. Especially information on the vulnerable systems may be
inaccurate or wrong. Possibly supplied exploit code is not to be used
for malicious 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
include link .
================= Not this time. Not here.
-. email@example.com -. + http://segfault.net/~scut/
`--------------------. -' segfault.net/~scut/pgp `' 5453 AC95 1E02 FDA7
50D2 A42D 427E 6DEF 745A 8E07 `- AFIWC control and information seized.
awaiting orders. hi echelon --------'
Content-Type: application/pgp-signature; name="untitled-2"
Content-Disposition: attachment; filename="untitled-2"