|
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
believe me.
ciao,
-scut
------
TESO Security Advisory
07/18/2001
Multiple vendor Telnet Daemon vulnerability
Summary
===================
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.
Systems Affected
===================
System | vulnerable |
exploitable *
----------------------------------------+--------------+------------------
BSDI 4.x default | yes |
yes
FreeBSD [2345].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 may
have overseen things. Do not rely on this.
Details about the systems can be found below.
Impact
===================
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.
Explanation
===================
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 (14336).
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 mind.
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.
Solution
===================
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.
Acknowledgements
===================
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 scut.
Contact Information
===================
The TESO crew can be reached by mailing to teso@team-teso.net
Our web page is at http://www.team-teso.net/
References
===================
[1] TESO
http://www.team-teso.net/
Disclaimer
===================
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 [1].
Exploit
===================
Not this time. Not here.
------
--
-. scut@nb.in-berlin.de -. + 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 --------'
|
