RE: Telnetd AYT overflow scanner and linux telnet 0.17

["Dawes, Rogan (ZA - Johannesburg)" <rdawes () deloitte co za>]

[Resent after 4 days passed and not seen on the list]

Hi,

I ran the Perl code supplied by David Maxwell (on Bugtraq) against Linux
with telnet 0.17-7,
and saw some funny results.

These results appear to depend on the length of the hostname of the attacked
machine.
Originally, the machine was called "neo.iss.deloitte.co.za", and I saw
changes after the 243'rd server response:


[240 similar responses deleted]

[neo.iss.deloitte.co.za : yes]^M
^M
[neo.iss.deloitte.co.za : yes]^M
^M
[neo.iss.deloitte.co.za : yes]^M
^M
[neo.iss.deloitte.co.za ^M^M[neo.iss.deloitte.co.za : yes]

Note the missing ":yes", and the fact that they now start staying on the
same line, whereas before they were on their own lines. This line continues
for 8225 characters in all, and ends with:

[neo.iss.deloitte.co.za : yes]^M^M[neza : yes]^M

Note the neza, which, to my mind, is the hostname with the middle of the
name cut out.

Also, depending on the name of the victim, there seems to be another error
as well. Having set my hostname to 1 character "n", and saving the output of
the negotiation stream to a file, I saw:

# perl -e 'for ($i=0;$i<1939;$i++) { print "\377\366" }' | nc -v 127.0.0.1
telnet > telnetd_exp8 
-rw-r--r--    1 root     root        25219 Jul 27 09:18 telnetd_exp8

# perl -e 'for ($i=0;$i<1940;$i++) { print "\377\366" }' | nc -v 127.0.0.1
telnet > telnetd_exp8
-rw-r--r--    1 root     root           12 Jul 27 09:18 telnetd_exp8

For a 3 character hostname, the cut-off was 1681-1682

I have no idea how to take this further, but if anyone is interested in more
testing on this computer, drop me a mail, please.

Rogan

> From a gdb session:

[root@neo /root]# perl -e 'sleep 10; for ($i=0;$i<512;$i++) { print
"\377\366" }' | nc 127.0.0.1 telnet

[root@neo /root]# rpm -qa | grep telnet
telnet-0.17-7

[root@neo /root]# ps auwx | grep telnet
root     14838  0.2  1.9  1340  596 pts/1    S    08:41   0:00 nc -v
127.0.0.1 telnet
root     14839  0.8  2.3  1644  704 ?        S    08:41   0:00 in.telnetd
[root@neo /root]# gdb
GNU gdb 5.0
This GDB was configured as "i386-redhat-linux".
(gdb) attach 14839
Attaching to Pid 14839
0x401285f4 in ?? ()
(gdb) continue
Continuing.

Program exited with code 01.
(gdb) 


-----Original Message-----
From: aleph1 () securityfocus com [mailto:aleph1 () securityfocus com]
Sent: 26 July 2001 11:21
To: bugtraq () securityfocus com
Subject: Re: Telnetd AYT overflow scanner


Summary of responses on this thread:

From: Homer Wilson Smith <homer () lightlink com>

  Inconsistent results on Linux 2.0.38 running older libc.

  Script started on Wed Jul 25 16:10:02 2001
  superoot emerald/root: ayt romance

  Telnetd AYT overflow scanner, by Security Point(R)
  Host: romance
  Connected to remote host...
  Sending telnet options... stand by...
  Telnetd on romance vulnerable

  superoot emerald/root: ayt romance

  Telnetd AYT overflow scanner, by Security Point(R)
  Host: romance
  Connected to remote host...
  Sending telnet options... stand by...
  Telnetd on romance not vulnerable


From: Rick Crelia <rcrelia () cobaltgroup com>

  I can corroraborate your findings. The SPtelnetAYT scanner is producing
  "hits" on Linux boxes (2.0.x, 2.2.x, variety of Netkits) whereas the
  scut scanner said they were not vulnerable. This was also the case for
  Solaris 7 and Solaris 8 boxes with the latest Sun patch clusters.

  As of today, it looks like OpenBSD 2.9 and the latest Netkit for Linux
  are known to be not vulnerable.


From: "Chirk C. Chu" <c3chu () alaska edu>
                                                 
  Based on the results from the Telnet AYT scanner provided by
  info () secpoint com SRP telnetd is vulnerable. Versions tested:
  1.7.1, 1.7.2 and 1.7.3.

  Red Hat 7.1 - SRP 1.7.3

    $ ./ttest kingpinz
    Telnetd AYT overflow scanner, by Security Point(R)
    Host: kingpinz
    Connected to remote host...
    Sending telnet options... stand by...
    Telnetd on kingpinz vulnerable

  Solaris 8 - SRP 1.7.2

    $ ./ttest snoopy
    Telnetd AYT overflow scanner, by Security Point(R)
    Host: snoopy
    Connected to remote host...
    Sending telnet options... stand by...
    Telnetd on snoopy vulnerable

  Tru64 4.0G - SRP 1.7.1

    $ ./ttest chaos
    Telnetd AYT overflow scanner, by Security Point(R)
    Host: chaos
    Connected to remote host...
    Sending telnet options... stand by...
    Telnetd on chaos vulnerable


From: Serguei Patchkovskii <patchkov () ucalgary ca>

  Unfortunately, this scanner generates false negatives. It reports
  Tru64 4.0d pl8 as not vulnerable. However, it causes telnetd on
  this system to dump core - which would presumably indicate that
  it -is- vulnerable.


From: GVB <gvb () abused com>

  Juniper Routers (running something based on one of the BSD's) are also
  vulnerable to this telnetd attack.


From: bow <bow () bow net>

  I tested this on a FreeBSD 3.4-RELEASE box and it responded "not 
  vulnerable". However, the telnetd daemon did signal 11 and core. Hmmm.

  Also I tested it on SCO 3.2 and "SCO OpenServer(TM) Release 5". They both
  returned "vulnerable".


From: tasos <stampolidis () city academic gr>

  Slackware 8 according to the scanner is vulnverable but the exploit 
  doesn't work. Slackware 8 uses linux netkit 0.17 which is not affected.
  Testing the scanner on a win2k w/ SP2 it crashed the telnetd. Couldn't
  run the exploit against the server.


From: "Leandro Quibem Magnabosco" <leandro () funcitec rct-sc br>


  I've tested on Redhat 7.1 and it is vulnerable.

  Telnetd AYT overflow scanner, by Security Point(R)
  Host: 200.135.30.1
  Connected to remote host...
  Sending telnet options... stand by...
  Telnetd on 200.135.30.1 vulnerable

  Fortunatedly, I'm not using telnet on this server, so... I've disabled it.


From: "Willem" <imailtest () onlineok com>

  I ran the scanner aginst a slack 7.1 and a 8.0 box to see what would 
  happen and it said it was vulernable. If it really is or not i dunno.


From: "Tom Stowell" <jts () deforest k12 wi us>

  XCONSOLE (actually, TELNETD.NLM) for NetWare 5.1 SP2a appears to be 
  vulnerable, although I didn't observe any direct or indirect effects of 
  the overflow (i.e.:the service continued responding to requests normally,
  and no error messages were printed to the server console or the logs).


From: Jonas Eriksson <je () sekure net>

  I can confirm that the following Nokia IPSO releases are not vulnerable 
  to the telnetd bug:

  * IPSO-3.2.1-fcs1-11.24.1999-102644-849
  * IPSO-3.3-FCS3-09.14.2000-234849-567
  * IPSO-3.4-FCS4A-06.26.2001-235900-767


-- 
Elias Levy
SecurityFocus.com
http://www.securityfocus.com/
Si vis pacem, para bellum