|
************************************************************************
Product: netkit telnet protocol daemon, in.telnetd
Version: netkit-telnet-0.17 (and previous)
/usr/sbin/in.telnetd
Severity: High
Remote: Yes
Allows: Remote ROOT level access.
Workaround: Disable telnet access.
Fix: Check with your vendor for an updated package.
************************************************************************
<from http://www.securityfocus.com/archive/1/197804, posted by
<scut@nb.in-berlin.de>.
To: BugTraq
Subject: multiple vendor telnet daemon vulnerability
Date: Wed Jul 18 2001 22:15:10
...
System | vulnerable |
exploitable *
----------------------------------------+--------------+------------
... | |
Linux netkit-telnetd >= 0.14 | no |
... | |
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.
...
<end of message>
TESO were wrong about netkit >=0.14 not being vulnerable.
************************************************************************
Requires: Currently running telnet daemon (often on by default)
/usr/in.telnetd <= netkit-telnet-0.17
(telnet-0.17-7 is the default in.telnetd for Redhat 7.0)
GLIBC > 2.0.6
************************************************************************
Description of problem:
The version of /usr/sbin/in.telnetd that comes as default on
Redhat 7.0,
and many other distributions contains an exploitable overflow in
the
handling of its output, allowing execution of arbitrary commands.
The problem is in the handling of the AYT commands, as described
in the
advisory already linked.
************************************************************************
Exploit details: (the attached file zp-exp-telnetd.c)
If the user has local access to the system, it is possilble to
get the
program to set arbitrary environment variables in the
environment of
/bin/login.
e.g. LD_PRELOAD=/tmp/make-rootshell.so
By filling the heap, in a similar way to the teso exploit, it
its possible
to set 2 or more environment variables.
If the user doesn't have local access, it is possible to
overwrite the
chunk header information for a pointer used by setenv(3), and
store a new
chunk in a user controllable location, so when the envrionement
gets
reallocated it will change the value of arbitrary memory
locations.
e.g. You could cause the pointer to set the length of the
previous chunk
to the distance back from the chunk to a point in netibuf, which
itself
contains a chunk to set the address of a function in the GOT to
point to
shellcode, which could also be stored in the network input
buffer.
Sometimes bad things happen that you have to kludge to fix. e.g.
push_clean() in the proof of concept exploit. Sometimes I got
some
characters from the previous input being sent again, and when
that was a
command to set an environment variable or something else that
changed the
environment, it kinda messed with malloc calculations a little.
As it is, this exploit will probably not work on your machine,
but
carefully modifying appropriate values should fix that.
-- zen-parse
____ http://mp3.com/cosv _______
/ ___\ __ _______ / _____/ __
/ /_____/ \ / ____ \ / / ______/ \__________
\______ /\ \__\ \ \ \ / / /_gone_\__/_platinum_\
\ \/ ______/ \ \/ / \______/ \__________/
\__/ \__/ \__/
-- ObPlug: Buy our CD!
-- Available: For work in the security industry. (email for
details)
-------------------------------------------------------------------------
The preceding information, unless directly posted by
zen-parse@gmx.net to
an open forum is confidential information and not to be
distributed
(without explicit permission being given by zen-parse@gmx.net).
Legal
action may be taken to enforce this. If you are mum or dad, this
probably
doesn't apply to you.
|
