Below is the original message sent to Microsoft, and since apparently 'Disclosure Procedures' are once again in focus...
11/08/2000 - Issue is reported to Microsoft's Security Response Team (firstname.lastname@example.org) 11/10/2000 - Microsoft confirmed receipt 11/21/2000 - Microsoft responded that they reproduced the issue, and were evaluating code changes 11/30/2000 - Due to the expiration of the 21-days vendor-response period, the issue is made public
-----Original Message----- From: Alexander Ivanchev [mailto:email@example.com] Sent: Thursday, November 09, 2000 16:22 To: firstname.lastname@example.org Subject: Windows 2000 Telnet Service DoS
I'd like to report the following issue with Windows 2000's Telnet Service Daemon:
System Environment: Windows 2000 Professional Final Build [Version 5.00.2195] Service Pack 1, All latest windowsupdate.com security updates (as of 11/08/2000) Telnet Service Build 5.00.99201.1
Classification Denial of Service, possible code problems
Details a. DoS - The Telnet Service in question is vulnerable to a simple Denial of Service attack. The problem apparently lies within the login routine of the daemon. The problem can be demonstrated by telneting to a machine running the specified version of the Telnet Service and waiting at the login/password prompt until a session timeout takes place. However, after it does time out the connection is not reset by the daemon until the user presses a key. In Windows 2000 Professional, due to the fact, it allows only one telnet connection per host, this will effectively disable access for the authorized user. We did not test the problem with Server/Advanced Server/Datacenter but I believe that by establishing the maximum number of allowed connections and not terminating them would result in the same problem. Thus, this constitutes a Denial of Service attack. Theoretically, it is also quite possible to exhaust server side sockets if there is not a limit imposed on the maximum number of telnet sessions. b. Possible code problem - On the Windows 2000 Professional test machine the above vulnerability was tested, the following strange behavior of the telnet service was observed: By establishing a telnet session, and not terminating it, during the wait interval, attempts to establish a different telnet session fail with the following message:
Microsoft Windows Workstation allows only 1 Telnet Client License Server has closed connection
Connection to host lost.
However, when a connection is attempted AFTER the session had timed out, but it is still not reset, SOMETIMES the following return message would result:
~r?q?LL>ECHELON?ECHELON?ECHELON?echelon?echelon Microsoft Windows Workstation allows only 1 Telnet Client License Server has closed connection
Connection to host lost.
Where ECHELON is the hostname of the machine. Needless to say, this does not seem right.
c. Note: When a machine comes under the above-described attack, the 'List the current users' telnet admin option will NOT report established connections, since a login would not have taken place, even though the number of allowed connections could have been reached. (This of course could be easily discovered using netstat or an equivalent utility)
Credits The above problems were discovered and tested by Alexander Ivanchev of Breach Technologies. Alexander Ivanchev can be reached at email@example.com or firstname.lastname@example.org
Disclosure Policy Breach Technologies will wait for 21 days since the message is sent, before disclosing details about the above matter. If an official advisory/patch is/are released before this period ends, disclosure will take place earlier
Feedback Policy Please feel free to contact us with questions, corrections and comments regarding these issues.
Thank you for your time and attention!