************************************************************************ 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 <scutat_private-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-parseat_private to an open forum is confidential information and not to be distributed (without explicit permission being given by zen-parseat_private). Legal action may be taken to enforce this. If you are mum or dad, this probably doesn't apply to you.
This archive was generated by hypermail 2b30 : Thu Aug 09 2001 - 09:51:12 PDT