COMMAND

    telnet service

SYSTEMS AFFECTED

    Windows 2000

PROBLEM

    Following  is  based  on  a  Microsoft Security Bulletin MS01-031.
    That bulletin discusses a total of seven vulnerabilities affecting
    the Windows 2000  Telnet service.   The vulnerabilities fall  into
    three  broad  categories:  privilege  elevation, denial of service
    and information disclosure.

    Two of  the vulnerabilities  could allow  privilege elevation, and
    have their roots in flaws  related to the way Telnet  sessions are
    created.  When  a new Telnet  session is established,  the service
    creates a  named pipe,  and runs  any code  associated with  it as
    part of the initialization process.   However, the pipe's name  is
    predictable, and if Telnet finds an existing pipe with that  name,
    it simply uses it.   An attacker who had  the ability to load  and
    run  code  on  the  server  could  create the pipe and associate a
    program with  it, and  the Telnet  service would  run the  code in
    Local System context when it stablished the next Telnet session.

    Four of the vulnerabilities could allow denial of service attacks.
    None of these  vulnerabilities have anything  in common with  each
    other.
    - One  occurs  because  it  is  possible  to  prevent Telnet  from
      terminating idle  sessions; by  creating a  sufficient number of
      such  sessions,  an  attacker  could  deny sessions to any other
      user.
    - One occurs  because of a  handle leak when  a Telnet session  is
      terminated in a  certain way.   By repeatedly starting  sessions
      and then terminating them, an attacker could deplete the  supply
      of  handles  on  the  server  to  point where it could no longer
      perform useful work.
    - One  occurs  because  a  logon  command containing a  particular
      malformation causes an access violation in the Telnet service.
    - One occurs because a system  call can be made using only  normal
      user privileges, which  has the effect  of terminating a  Telnet
      session.

    The final vulnerability is an information disclosure vulnerability
    that could make it easier  for an attacker to find  Guest accounts
    exposed via  the Telnet  server.   It has  exactly the same cause,
    scope and effect as a vulnerability affecting FTP and discussed in
    Microsoft Security Bulletin MS01-026:

        http://oliver.efri.hr/~crv/security/bugs/NT/iis101.html

    Privilege elevation vulnerabilities
    ===================================
    Because the attacker would need  the ability to load and  run code
    on  the  Telnet  server,  it  is likely that these vulnerabilities
    could only be exploited by an attacker who had the ability to  run
    code locally on the Telnet Server.  Administrative privileges  are
    needed to  start the  Telnet service,  so the  attacker could only
    exploit the vulnerability  if Telnet were  already started on  the
    machine.

    Denial of service vulnerabilities
    =================================
    It would not be necessary to reboot the server to recover from any
    of these vulnerabilities.  At worst, the Telnet service would need
    to be restarted.  None  of these vulnerabilities could be  used to
    gain  additional  privileges  on  the  machine; they are denial of
    service vulnerabilities only.

    Information disclosure vulnerability
    ====================================
    The vulnerability could only be exploited if the Guest account  on
    the local machine was disabled, but the Guest account on a trusted
    domain was enabled.  By default, the Guest account is disabled.

    Acknowledgment:
    - Guardent for reporting the two privilege elevation bugs and  one
      of the denial of service vulnerabilities.
    - Richard Reiner  of Securexpert for  reporting one of  the denial
      of service vulnerabilities.
    - Bindview's Razor Team for reporting one of the denial of service
      vulnerabilities.
    - Peter Grundl for reporting one of the denial of service bug.

    Here  is  what  Razor  Team  have  found.   There is a buffer size
    checking related fault condition in Microsoft Windows 2000  telnet
    server.  This vulnerability is  present only if telnet service  is
    running and plain-text logins are allowed (this does not apply  to
    NTLM-based authentication).

    Microsoft  Telnet  Server  does  range  checking  when  reading  a
    username, dropping the connection if an excessively long line  was
    sent to it.  This  mechanism fails if there is  approximately 4300
    or more characters in the input buffer already, and ASCII code 127
    (0x7b,  backspace)  arrives.   This  leads  to  service crash (DoS
    condition).  When this  condition occurs, 0x41414141 can  be found
    in stack  dumps.   Microsoft advised  that this  condition is  not
    exploitable.

    The following Linux bash script  would test telnet server for  the
    vulnerability:

        #!/bin/bash
        ( sleep 1
          perl -e '{printf "%s\x7f%s","A"x4500,"A"x100}'
          sleep 3
        ) | telnet victimbox

SOLUTION

    A patch is available to  fix this vulnerability.  Please  read the
    Security Bulletin

        http://www.microsoft.com/technet/security/bulletin/ms01-031.asp

   for information on obtaining this patch.  Windows 2000:

        http://www.microsoft.com/Downloads/Release.asp?ReleaseID=30508