Microsoft Security Bulletin MS01-031

Technical description:

This 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 established 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.

Mitigating factors:

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.

Vulnerability identifier:

Privilege elevation vulnerabilities:

• CAN-2001-0349
• CAN-2001-0350

Denial of service vulnerabilities:

• CAN-2001-0345
• CAN-2001-0346
• CAN-2001-0348
• CAN-2001-0351

Information disclosure vulnerability:

• CAN-2001-0347

Tested Versions:

Microsoft tested Windows 2000 and Windows NT® 4.0 to assess whether they are affected by this vulnerability. Previous versions are no longer supported and may or may not be affected by this vulnerability.

How are the vulnerabilities discussed in this bulletin related to each other?
The vulnerabilities are unrelated to each other except by the fact that all of them involve the Windows 2000 Telnet service.

What are the vulnerabilities?
There are a total of seven vulnerabilities here, falling into three general categories:

• Two vulnerabilities that could enable an attacker to gain privileges on a Telnet server.
• Four vulnerabilities that could be used to disrupt Telnet services.
• One vulnerability that could make it easier for an attacker to gain access to a poorly configured network via the Telnet service.

What's the scope of the first set of vulnerabilities?
The first two vulnerabilities areprivilege elevation vulnerabilities. Exploiting either of these vulnerabilities could enable an attacker to gain full control over an affected server, and enable her to take any desired action on it.
These vulnerabilities share a significant restriction - exploiting either would require the attacker to already have the ability to put a program of her choice onto the server and run it. In most cases, this would require the attacker to have local logon rights to the affected server.

What causes the vulnerabilities?
Both vulnerabilities result because of the same underlying problem in the way the Telnet service handles server-side named pipes. Through a flaw similar to the one discussed in Microsoft Security Bulletin MS00-053, Telnet could be made to use a named pipe that the attacker had created, thereby causing Telnet to execute any code contained in the named pipe.

What's a named pipe?
A pipe is an area of memory that two or more processes share, and which enables them to communicate with each other. When Process A wants to communicate with Process B, it puts data into the shared memory and sets a semaphore telling Process B to read it. There are two types of pipes:

• Anonymous pipes, which allow one-way communication from a parent process to a child process. They can only exist locally.
• Named pipes, which allow bi-directional communication between multiple processes. The processes can reside on different machines.

These two vulnerabilities result because of the way the Telnet service handles named pipes when it starts a new Telnet session.

What's wrong with the way Telnet uses named pipes?
Each time Telnet starts a new session, it creates a named pipe and assigns it to the session. Any code attached to the named pipe is executed as part of the initialization process. The vulnerabilities results because Telnet chooses predictable names for the pipes and, if a pipe with the designated name already exists, Telnet will use it.

Why does this cause a pair of security vulnerabilities?
Because Telnet's naming algorithm is predictable, it could be possible for an attacker to guess the name of the pipe that the server will use for the next Telnet session it establishes. This would give her the opportunity to create the pipe ahead of time and attach code of her choice to it. If she did this, the Telnet service would use the pipe and run the code for her.

What security context would the code run in?
The code would run in the security context of the Telnet service - Local System. This would give the attacker's code the ability to take any desired action on the server.

What's the difference between the two vulnerabilities?
The two vulnerabilities differ primarily in the way they exploit the underlying problem regarding named pipe creation.

Would the vulnerabilities enable an attacker to take over an entire domain? 
The risk to the domain would depend on the specific machine that was compromised, and the role it plays on the network. If a stand-alone server were compromised, it would likely pose little risk to the network at large because, by default, even a local administrator has no special domain privileges.
However, if a domain controller or other machine that stores domain administrative information locally were compromised, the malicious user could take advantage of it to extend control beyond the local machine. However, the fact that domain controllers and similar machines store domain administrative information is one reason why recommended security practices suggest not using them as Telnet servers.

How would the attacker create the named pipe?
Named pipes can only be created under program control, and only on the local machine. This is an important point, because it means the attacker could only exploit the vulnerability if she had the ability to load a program onto the server and run it.
In general, this would require that the attacker have the ability to log onto the server interactively. However, best practices strongly recommend against giving unprivileged users the ability to log onto servers like these interactively. If this advice has been followed, the attacker wouldn't be able to exploit either vulnerability.

Could an attacker exploit these vulnerabilities via a Telnet session?
Although these vulnerabilities involve the Telnet service, it's unlikely that an attacker could exploit either one through a Telnet session. A Telnet session might provide the attacker with a way to run a program, but it wouldn't give her any way of loading her program onto the server. This is the principal reason why it's likely that the attacker would need interactive logon rights in order to exploit the vulnerabilities

If they can't be exploited via a Telnet session, how could they be exploited?
The most likely exploit scenario would be one involving a dual-use machine - for instance, a terminal server that had the Telnet service running in order to, for instance, allow the administrator to manage it remotely.

If an attacker already had interactive logon rights to a machine, could she start the Telnet service as a way of exploiting the vulnerabilities?
Remember that it take administrative access to start the Telnet service. If the attacker were able to start Telnet on a machine, she would by definition already have complete control over the machine.

How does the patch eliminate the vulnerabilities?
The patch eliminates the vulnerabilities improving the randomness with which named pipes' names are selected by the Telnet service.

What's the scope of the second set of vulnerabilities?
These are denial of service vulnerabilities. These vulnerabilities could enable an attacker to prevent legitimate users from using the Telnet server, by monopolizing server resources, disrupting server operation, or accessing management functions that should be denied to unprivileged users. The following section discusses each vulnerability.

What causes the first denial of service vulnerability, and how could an attacker exploit it?
This vulnerability results because it's possible to prevent an idle Telnet session from timing out. By starting as many sessions as the server could accommodate, and letting them idle in a particular way, an attacker could prevent other users from establishing Telnet sessions.

What causes the second denial of service vulnerability, and how could an attacker exploit it?
This vulnerability results because when a Telnet session is severed in a particular way, certain resources called handles aren't returned to the system for reuse. By repeatedly establishing and severing Telnet sessions, an attacker could deplete the server resources to the point where the server could be become unresponsive or fail altogether. The administrator could restore normal service by restarting the Telnet session.

What causes the third denial of service vulnerability, and how could an attacker exploit it?
This vulnerability results because the Telnet service does not correctly handle a logon command containing a particular deformity. If an attacker entered such a command, it would cause the Telnet service to fail. The administrator could restore normal service by restarting the Telnet session.

What causes the fourth denial of service vulnerability, and how could an attacker exploit it?
This vulnerability results because, although the management console for the Telnet service requires administrative privileges, some of the underlying system calls do not. In particular, a program running with normal privileges could make system calls to terminate a Telnet session. If an attacker had the ability to load and run a program on a Telnet server, she could terminate any Telnet session she wanted to.

Would these vulnerabilities prevent a server from performing other work?
Only the second vulnerability would impede the server in performing other work. In the case of the other three vulnerabilities, the server would continue functioning normally, except for the fact the Telnet services would be disrupted.

Would any of these vulnerabilities give the attacker a way to gain administrative control over the machine?
No. These are denial of service attacks only, and don't provide any way for the attacker to elevate her privileges on the machine, compromise data, or take any other action.

Could these vulnerabilities be exploited from the Internet?
The first three vulnerabilities could be exploited against an Internet-connected server. The fourth vulnerability, however, would require that the attacker be able to load a program onto the server and run it. In most cases, this would require that she have the ability to log onto the server interactively.

How does the patch eliminate these vulnerabilities?

• The patch eliminates the first vulnerability by causing the idle timeout clock to run under all conditions. This ensures that idle sessions are terminated.
• The patch eliminates the second vulnerability by ensuring that all resources allocated to Telnet sessions are returned to the operating system at the conclusion of the session.
• The patch eliminates the third vulnerability by treating the deformed logon command as an invalid one.
• The patch eliminates the fourth vulnerability by moving security checks from the management console to the underlying system calls.

What's the scope of the final vulnerability? 
This is an information disclosure vulnerability. It would not give an attacker a way to do anything she couldn't already do, but it would make it easier for her to exploit a mis-configured network. In the worst case, the vulnerability could assist an attacker in gaining access to a domain account.
This vulnerability has a number of significant restrictions:

• The attacker would need to know the correct password for the account. The most likely account to be affected -- the Guest account - is disabled by default.
• The vulnerability could only be exploited if the system administrator had made the Telnet server a domain member.

This vulnerability sounds familiar. Is it similar to a previously discussed vulnerability?
Yes. In fact, it's a precise parallel to the information disclosure vulnerability affecting the FTP service, which was discussed in Microsoft Security Bulletin MS01-026.

What causes the vulnerability?
The vulnerability results because, if a userid is specified in a particular way when a user logs onto an affected Telnet server, the system will automatically search all trusted domains for a userid that matches it. If the userid is found and the correct password is provided, the system will allow the user to log into it normally.

What do you mean by a trusted domain?
Domains in Windows NT and Windows 2000 can enter into trust relationships, in order to allow users in one domain to access resources in another. For instance, the administrator of Domain A might agree to trust Domain B, thereby allowing users in Domain B to access and use servers, files, and other resources in Domain A. This is referred to as a trust relationship because Domain A (the trusting domain) is agreeing to trust Domain B (the trusted domain) when it vouches for the identities of its users.

What does this have to do with Telnet?
Domain trusts matter to Telnet because they affect who can log onto an Telnet server. A user can always log onto an Telnet server via a user account that's local to the server itself. However, if the server is a domain member, a user can also log onto the server via one of the domain user accounts. Finally, if the server is a member of a domain that trusts another domain, a user can log onto the server via one of the trusted domain's user accounts. Of course, the user would need to know the password for any user account she wanted to log into.

How does the server know whether to log the user into a local user account or a domain one?
It depends on how the user enters the account name. If she entered only the account name by itself - for instance, "Jane" - the server would attempt to log her onto the server using a local account. If she wanted to log into a domain account, she would need to preface the user account name with the domain name - for instance, DomainA\Jane.

Is there any way for a user to determine what accounts are available?
By design, there should be no way for a user to determine which accounts exist, either on the local machine, in the domain the machine belongs to, or in any trusted domains. The user should need to already know the user account name and the domain name in order to begin the login process. This vulnerability doesn't remove this safeguard, but it does weaken it.

What's the vulnerability?
If a user enters a user account name that's prefaced with a particular set of characters, the Telnet service won't require that she provide the name of the domain the account belongs to. Instead, it will search the server's domain and all of the domains it trusts for a user account name that matches the one the user entered. If one is found, and the user enters the right password for that account, it will log her onto the server.

What's so bad about that? The user did know the password, after all.
The user shouldn't be able to log into a domain user account without knowing and specifying the domain name. Of course, an attacker could always conduct a brute-force attack and simply try every possible domain name and user account name. However, this vulnerability clearly would make an attack much easier.

But the user would still need to know or guess the name of a valid domain user account, right?
That's correct, and as a result, it's likely that this vulnerability would only be useful in a few scenarios. In particular, it would be helpful in mounting an attack involving the Guest account, because that account has both a well-known account name and a well-known password. If enabled, the Guest account's default password is blank.
To see why this would provide an advantage to an attacker, suppose a Telnet server was a member of a domain that trusted 20 other domains, and suppose the Guest account in Domain15 had inadvertently been enabled. If an attacker entered "Guest" as the account name (prefaced, of course, by the correct characters), this vulnerability would cause the Telnet service to search all of the trusted domains, and then log the user into Domain15\Guest. By entering a blank password, the attacker would gain access to the Domain15\Guest account.

But suppose the Guest account on the local machine was disabled. What then?
It wouldn't prevent the attacker from logging into the Domain15\Guest. However, there is one aspect of this issue that's worth considering. If the Guest account on the local machine had been enabled, the vulnerability could not be exploited, because the Telnet service would try to log the attacker into the local Guest account.

But if I enable the local Guest account, I would still be giving untrusted users access to my server, wouldn't I?
Actually, you wouldn't. The Telnet service will not allow logins to the local Guest account, even when it's enabled. In other words, if you enabled the local Guest account, it would prevent an attacker from exploiting this vulnerability, but still wouldn't let him log into the local Guest account. Of course, the best way to prevent the vulnerability would be to apply the patch.

What could an attacker do if she exploited this vulnerability and gained access to a domain Guest account?
It depends on the privileges the account has been given on the domain. In the example above, the attacker would be able to do anything the Domain15\Guest account was allowed to do. Typically, the Guest account has few privileges, but it is a member of the Everyone group and as a result would be able to view, add or change certain files.

Suppose the Domain15\Guest account had been configured to have a non-blank password. What then?
The attacker couldn't log on unless she knew the password. Nothing in this vulnerability allows the attacker to learn the password for the account. Indeed, that's why we've focused the discussion on the Guest account - it's one of the few that, if enabled, have a well-known default password.

What does the patch do?
The patch returns the Telnet service to its by-design operation, and causes it to only log a user into a domain account if the domain name is correctly specified.

Download locations for this patch

• Microsoft Windows 2000 Professional, Server, Advanced Server:

  http://www.microsoft.com/downloads/details.aspx?FamilyId=0D0032E7-259D-4F68-BF08-B0A7CAA1FD1C&displaylang=en

• Microsoft Windows 2000 Datacenter Server:

  Patches for Windows 2000 Datacenter Server are hardware-specific and available from the original equipment manufacturer.