Microsoft Security Bulletin MS02-004 - Moderate
Unchecked Buffer in Telnet Server Could Lead to Arbitrary Code Execution
Published: February 02, 2002 | Updated: May 09, 2003
Originally posted: February 07, 2002
Updated: May 09, 2003
Who should read this bulletin: System administrators using Microsoft® Windows® 2000 or Microsoft Interix 2.2
Impact of vulnerability: Denial of Service, possibly Run code of attacker's choice
Maximum Severity Rating: Moderate
Recommendation: System administrators should apply the patch to all systems that offer affected Telnet services.
- Telnet Service in Microsoft Windows 2000
- Telnet Daemon in Microsoft Interix 2.2
The Telnet protocol provides remote shell capabilities. Microsoft has implemented the Telnet protocol by providing a Telnet Server in several products. The implementations in two of these products - Windows 2000 and Interix 2.2 - contain unchecked buffers in the code that handles the processing of telnet protocol options.
An attacker could use this vulnerability to perform a buffer overflow attack. A successful attack could cause the Telnet Server to fail, or in some cases, could possibly allow an attacker to execute code of her choice on the system. Such code would execute using the security context of the Telnet service, but this context varies from product to product. In Windows 2000, the Telnet service always runs as System; in the Interix implementation, the administrator selects the security context in which to run as part of the installation process.
- While the Telnet Service in Windows 2000 is installed by default, it is not running by default. As a result, a Windows 2000 system would only be vulnerable if the administrator had started the service
- Remotely exploiting this vulnerability would require the attacker to have the ability to connect to the Telnet Server. Best practices recommends against allowing Telnet access on uncontrolled networks.
- The Telnet Daemon in Interix 2.2 is not installed by default when Interix 2.2 is installed. An administrator would have to choose to install and configure this feature.
- The Telnet Daemon in Interix does not specify a security context by default. The administrator specifies the security context when they configure or run the daemon. Best practices recommend that the Telnet Daemon run in a context of least privilege, meaning that it have only those rights necessary and no more.
|Internet Servers||Intranet Servers||Client Systems|
|Telnet Service in Microsoft Windows 2000||Moderate||Moderate||Moderate|
|Telnet Daemon in Microsoft Interix 2.2||Low||Low||Low|
The above assessment is based on the types of systems affected by the vulnerability, their typical deployment patterns, and the effect that exploiting the vulnerability would have on them. In the case of the Windows 2000 Telnet Service, the service is not running by default, making the default installation not vulnerable. In the case of the Interix Telnet Daemon, this is not installed by default and requires specific security settings by the administrator. Following best practices of least privilege should limit the scope of the vulnerability.
Vulnerability identifier: CAN-2002-00020
Microsoft tested Windows XP, Windows 2000, Services for UNIX 2.0 and Interix 2.2 to assess whether they are affected by this vulnerability. Windows NT 4.0 was not tested, as it does not ship with a Telnet server. Previous versions are no longer supported and may or may not be affected by this vulnerability.
Frequently asked questions
What's the scope of the vulnerability?
This is a buffer overflow vulnerability that affects two Microsoft products: the Telnet Service in Windows 2000 and the Telnet Daemon (telnetd) in Microsoft Interix 2.2. By sending a specially malformed request to the telnet server, an attacker could produce either of two results. In the simpler case, this could cause the telnet server to fail. In the more complex case, this could allow an attacker to execute code of their choice on the system. Best practices recommend very strongly that Telnet should only be used on a fully trusted network. Telnet should not be used across the Internet and Telnet connections should be blocked at the corporate firewall. Neither Windows 2000 nor Interix are affected by by this vulnerability under default conditions.
What causes the vulnerability?
The vulnerability results because of an unchecked buffer in a part of code that handles the Telnet protocol options. By submitting a specially specific malformed packet, a malicious user could overrun the buffer.
Telnet is an industry standard protocol that allows a user to establish a remote terminal session on a telnet server. Because this is a terminal session, there is only a command-line interface. Telnet is mainly used for simple remote administration via the command prompt. Several Microsoft products contain implementations of the Telnet protocol. However, the vulnerability at issue here affects only two of these implementations - the ones in Microsoft Interix and Windows 2000.
What's Microsoft Interix?
Microsoft Interix is a product that allows customers to run UNIX application on a Windows system. Providing this capability expands support for UNIX applications, daemons, and scripts by provides an enhanced UNIX environmental subsystem beyond the standard POSIX subsystem in Windows 2000. It allows customers to run UNIX applications, daemons and scripts on Windows NT and Windows 2000.
What's a daemon?
In UNIX, a networking service like Telnet is called a daemon. Often, the actual program for the service is named with a "-d" at the end, to indicate that it is a daemon. Because the Telnet server in Interix is actually a UNIX program rather than a Win-32 program, it's referred to as a daemon for accuracy. In this case, the program in question is /bin/telnetd and /usr/sbin/in.telnetd.
What could an attacker do with this vulnerability?
An attacker could attempt to overrun the buffer with a large quantity of data. If an attacker supplied a large enough quantity of random data, she could cause the Telnet server to fail. If the attacker supplied carefully crafted data, she could cause code of her choosing to run in the Telnet server's process space.
If an attacker successfully loaded malicious code, what security context would it execute in?
The code would run in the same context as the Telnet Service. The specific context depends on the product. For the Windows 2000 Telnet Service , the code would execute within the SYSTEM context. This would allow the attacker to execute commands with the same privileges as the operating system. This means the code could take any action, including reformatting the hard drive, spawning a remote command shell with SYSTEM privileges, installing programs, or shutting down the system. For the Telnet Daemon in Interix, the context in which the code executes depends on choices made by the administrator when configuring telnetd. The administrator specifics the context in which telnetd operates when starting telnetd or configuring it to start automatically. Any code loaded by a successful exploit of this vulnerability would thus execute in the context in which the administrator decided to run telnetd. For example, if telnetd were configured to run in the SYSTEM context, then malicious code would execute in that context and be able to act as part of the operating system. Alternately, if the administrator configured telnetd to run in the context of a specially limited account, malicious code would execute only within that context.
How could an attacker mount an attack by using this vulnerability?
An attacker could attempt to mount an attack against this vulnerability by sending malformed packets to the Telnet Service. Anyone who could connect to the Telnet Service could potentially be able to attempt to exploit this vulnerability.
Could an attacker exploit this vulnerability across the Internet?
If a Telnet server were accessible across the Internet, an attacker could use this vulnerability to attempt an attack on the server. However, most corporate firewalls block Telnet access at the firewall as a best practice. Also, most companies prohibit Telnet in their DMZ as a best practice. These steps would eliminate exposure to this vulnerability on the Internet.
What does the patch do?
The patch eliminates the vulnerability by instituting proper checking of data input.
Who should apply the patch?
Any one who is running the Windows 2000 Telnet Service or the Telnet Daemon (telnetd) in Interix.
I'm using the Telnet Server in Services for UNIX 2.0, do I need to apply the patch?
No, the Telnet Server in Services for UNIX 2.0 does not contain this flaw.
I have the Telnet Service for Windows 2000 installed, but not running, should I apply the patch?
If you have Telnet installed but are not using the service, you should first consider removing the service as a best practice. If you are not going to remove the service, you should apply the patch.
I'm running Windows 2000 Professional, am I vulnerable?
The Telnet Service for Windows 2000 is installed, but not running by default on Windows 2000 Professional. Customers running Windows 2000 Professional should apply the patch to protect themselves if the service is enabled.
Download locations for this patch
Telnet Service in Microsoft Windows 2000:
The single patch for this issue is no longer available.
The fix for this issue is included in Windows 2000 Security Roll-up Package 1
Microsoft Interix 2.2:
Additional information about this patch
This patch can be installed on systems running Windows 2000 Service Pack 1 or Windows 2000 Service Pack 2
This patch can be installed on systems running Microsoft Interix 2.2 Gold
Inclusion in future service packs:
The Telnet Service for Windows 2000 fix for this issue will be included in Windows 2000 Service Pack 3
Reboot needed: No
Superseded patches: MS01-039
Verifying patch installation:
Verify that the version of the in.telnetd binary is 2.2.428.1
Telnet Service for Windows 2000:
Verify that the version of Tlntsvr.exe is 5.0.33668.1
Localized versions of this patch are under development. When completed, they will be available at the locations discussed in "Obtaining other security patches".
Obtaining other security patches:
Patches for other security issues are available from the following locations:
- Security patches are available from the Microsoft Download Center, and can be most easily found by doing a keyword search for "security_patch".
- Patches for consumer platforms are available from the WindowsUpdate web site.
- Microsoft Knowledge Base article Q307298 discusses this issue and will be available approximately 24 hours after the release of this bulletin. Knowledge Base articles can be found on the Microsoft Online Support web site.
- Technical support is available from Microsoft Product Support Services. There is no charge for support calls associated with security patches.
Security Resources: The Microsoft TechNet Security Web Site provides additional information about security in Microsoft products.
The information provided in the Microsoft Knowledge Base is provided "as is" without warranty of any kind. Microsoft disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. In no event shall Microsoft Corporation or its suppliers be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages, even if Microsoft Corporation or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply.
- V1.0 (February 02, 2002): Bulletin Created.
- V1.1 (May 09, 2003): Updated download links to Windows Update.
Built at 2014-04-18T13:49:36Z-07:00 </https:>