Ryan Sweat wrote:
> This is also interesting. It exists in at least Redhat versions 5.2 - 7.2.
>
> % export DISPLAY=`perl -e 'print "%s"x9000'` ; telnet 0
> Trying 0.0.0.0...
> Connected to 0.
> Escape character is '^]'.
> Segmentation fault (core dumped)
>
> telnet client dies. Note that this only occurs when making a connection to
> a legitimate host with telnetd enabled. In this example I have in.telnetd
> running locally.
(NOTE: telnet is crashing, not telnetd)
Testing with netkit-telnet-0.17 (self compiled version with debugging):
$ gdb telnet
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-redhat-linux"...
(gdb) run 127.0.0.1
Starting program: /home/syzop/netkit-telnet-0.17/telnet/telnet 127.0.0.1
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
telnet: buffer overflow, losing data, sorry
Program received signal SIGSEGV, Segmentation fault.
0x8050ab9 in env_opt_add (ep=0x806c790 "DISPLAY") at telnet.cc:1215
1215 *opt_replyp++ = c;
(gdb) x/x opt_replyp
0x8073000: Cannot access memory at address 0x8073000.
(gdb) x/x 0x8072ffc
0x8072ffc: 0x25732573
(gdb) bt
#0 0x8050ab9 in env_opt_add (ep=0x806c790 "DISPLAY") at telnet.cc:1215
#1 0x805098e in env_opt_add (ep=0x0) at telnet.cc:1184
#2 0x8050808 in env_opt (buf=0x805f641 "\001ÿð", len=1) at telnet.cc:1108
#3 0x804fe62 in suboption () at telnet.cc:765
#4 0x8051102 in telrcv () at telnet.cc:1470
#5 0x805170d in Scheduler (block=1) at telnet.cc:1716
#6 0x80517c5 in telnet () at telnet.cc:1759
#7 0x804c2a1 in tn (argc=0, argv=0xbfffb5dc) at commands.cc:1789
#8 0x804e274 in main (argc=2, argv=0xbfffb644) at main.cc:243
-- from source (telnet.cc:1203-1216)--
for (;;) {
while ((c = *ep++)!=0) {
switch(c) {
case IAC:
*opt_replyp++ = IAC;
break;
case ENV_VALUE:
case ENV_VAR:
case ENV_ESC:
*opt_replyp++ = ENV_ESC;
break;
}
*opt_replyp++ = c; <-- The crash
}
Mmm anyway... looks like the crash happends because of the sending
of the long environment var and not because of the receiving of something
(at least not this time)...
I see something like reserving memory in env_opt_start which uses
OPT_REPLY_SIZE bytes, which is defined as 256.
Doesn't look "remote" exploitable (there's also nothing after opt_replyp
in memory [no saved eip or some nice var :(] or at least not in my tests,
so you gain nothing by the overflow).
Anyway, the loops without size checking... brrrrrrr, that doesn't look
very secure code :P (but maybe that's already known after the telnetd
exploit).
Syzop.
This archive was generated by hypermail 2b30 : Mon Nov 12 2001 - 14:53:39 PST