Bugtraq mailing list archives

ADV/EXP: netkit <=0.17 in.telnetd remote buffer overflow


From: <zen-parse () gmx net>
Date: Fri, 10 Aug 2001 00:14:03 +1200 (NZST)

************************************************************************
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.

Attachment: netkit-telnet-0.17-ayt.patch
Description:

Attachment: zp-exp-telnetd.c
Description:


Current thread: