Microsoft Security Bulletin MS02-037

Technical description:

The Internet Mail Connector (IMC) enables Microsoft Exchange Server to communicate with other mail servers via SMTP. When the IMC receives an SMTP extended Hello (EHLO) protocol command from a connecting SMTP server, it responds by sending a status reply that starts with the following:

250-<Exchange server ID>Hello<Connecting server ID>

Where:

A security vulnerability results because of an unchecked buffer in the IMC code that generates the response to the EHLO protocol command. If the total length of the message exceeds a particular value, the data would overrun the buffer. If the buffer were overrun with random data, it would result in the failure of the IMC. If, however, the buffer were overrun with carefully chosen data, it could be possible for the attacker to run code in the security context of the IMC, which runs as Exchange5.5 Service Account.

It is important to note that the attacker could not simply send data to the IMC in order to overrun the buffer. Instead, the attacker would need to create a set of conditions that would cause the IMC to overrun its own buffer when it generated the EHLO response. Specifically, the attacker would need to ensure that a reverse DNS lookup would not only succeed, but would provide an FQDN whose length was sufficient to result in the buffer overrun.

Mitigating factors: 

Severity Rating: 

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. We have rated this vulnerability as a moderate one because of the difficulty of exploiting the vulnerability.

Vulnerability identifier: CAN-2002-0698 

Tested Versions:

Microsoft tested Exchange 2000 and Exchange 5.5 to assess whether they are affected by these vulnerabilities. Previous versions are no longer supported, and may or may not be affected by these vulnerabilities.

What's the scope of the vulnerability?
This is a buffer overrun vulnerability. In the worst case, it could enable an attacker to gain complete control over an affected Exchange server. In the more likely case, it could enable an attacker to cause the Exchange service to fail.
An attacker seeking to exploit this vulnerability would face a very daunting challenge. In most cases, exploiting the vulnerability would require the attacker to not only be able to establish a connection with a vulnerable mail server, but also be able to force the server to consult a DNS server of the attacker's choice during the attack.

What causes the vulnerability?
There is an unchecked buffer in the code within the Exchange 5.5 Internet Mail Connector that responds to the Extended Hello command. Under the conditions discussed below, it could be possible to cause the buffer to be overrun.

What is the Internet Mail Connector?
The Internet Mail Connector (IMC) is a component in Exchange Server that enables Exchange to interoperate with other vendors' mail servers. Exchange can use either of two protocols to communicate with other mail servers: a proprietary protocol that's used when communicating with another Exchange server; and Simple Message Transfer Protocol (SMTP), an industry-standard protocol that's used when communicating with third-party servers. The IMC is the part of Exchange that handles communications via SMTP. The Exchange IMC does not install by default. It is also sometimes referred to as the Exchange Server Internet Mail Service.

What's the Extended Hello command?
To explain the Extended Hello (EHLO) command, we first need to discuss SMTP Service Extensions. Although the SMTP protocol specifies a full set of basic mail operations, there also is a set of additional services and functions, called SMTP extensions, that many mail servers support. These are specified in RFC 1869. When two SMTP-based mail servers start a conversation, it's important for the server initiating the connection to learn which, if any, of the SMTP Service Extensions are supported by the other mail server. The EHLO command is part of this process. The message exchange between the two servers proceeds as follows:

What's wrong with how the EHLO command in the Exchange 5.5 IMC is implemented?
The IMC correctly handles the incoming EHLO command. However, the software that the IMC uses to formulate its response - specifically, the code used to construct the Hello in step 4 of the preceding question - contains an unchecked buffer. It could be possible for an attacker to construct a scenario in which responding to the Hello command would, through a fairly complex process, cause the IMC to generate data that would overrun its own buffer.

What would this enable an attacker to do?
Like many buffer overruns, this one could be used to accomplish either of two goals depending on the exact data that was provided. If the buffer was overrun using random data, the effect would be to cause the IMC to fail. On the other hand, if the buffer was overrun using carefully selected data, it could be possible to, in essence, modify the IMC process to perform tasks of the attacker's choosing. Because the IMC runs with system-level privileges, this would grant the attacker complete control over the server.

How might an attacker exploit this vulnerability?
Exploiting the vulnerability would be simple in theory: the attacker would need to create a suitable environment, then trigger an attack by connecting to a vulnerable Exchange 5.5 IMC and sending an EHLO command. Creating a suitable environment, however, could be quite difficult.

What do you mean by "a suitable environment"?
When the IMC responds to an EHLO command, it creates an initial response that identifies both servers, as discussed above. It identifies itself using its fully-quality domain name (FQDN) (e.g., "mailserver.microsoft.com"). It identifies the other server through either its IP address or its FQDN, depending on the circumstances.
By a "suitable environment", we mean one where the following conditions are true:

These conditions would cause the IMC to overrun its buffer, and this would cause the IMC to fail. To cause the IMC to overrun its buffer and run code of the attacker's choice, an additional condition would be required, namely, the other server's FQDN would need to include executable code.

What determines whether the IMC uses the other server's IP address or its FQDN?
The IMC always tries to use the other server's FQDN. However, to do this, it needs to do a reverse DNS lookup - that is, it needs to consult a DNS server, provide it with the IP address, and receive the corresponding FQDN in return. If the reverse DNS lookup failed for any reason, the IMC would use the IP address, and this would never cause the buffer to overrun.

How difficult would it be for the attacker to make the reverse DNS lookup succeed?
The attacker would need to provide bogus data to nearby DNS servers, and wait for the data to propagate to the DNS server being used by the vulnerable mail server. However, there's a hitch. The relevant industry standard places a maximum on how long an FQDN can be, and in most cases this value is smaller than what's needed to overrun the buffer. Thus, standards-compliant DNS servers likely would not accept the bogus data.
Instead, it's likely that the attacker would need to set up a DNS server and manually insert the bogus data. But that would mean that the attacker would need to ensure that the vulnerable IMC consulted the attacker's DNS server. Clearly, this would make exploiting the vulnerability quite difficult.

Is it possible to disable reverse DNS lookup?

Customers can disable Reverse DNS lookup on EHLO by setting a registry key as defined in Q190026. Customers that do this are protected from the buffer overrun.
Customers that do this are protected from the buffer overrun.
When reverse DNS lookup is disabled, the Internet Mail Service will no longer resolve the host name in the "Received From" portion of the SMTP message header to the fully qualified domain name, but instead use the Internet Protocol (IP) address in the form nnn.nnn.nnn.nnn. If the address is already in Internet Protocol (IP) form, the address will remain as such.

Does the vulnerability affect Exchange 2000?
No.

Does the vulnerability affect the SMTP service that ships in Windows 2000?
No.

How does the patch eliminate the vulnerability?
The patch institutes proper buffer handling in the Exchange 5.5 IMC code.

Download locations for this patch

Installation platforms:

This patch can be installed on systems running Microsoft Exchange 5.5 Service Pack 4.

Inclusion in future service packs:

None

Reboot needed: No

Patch can be uninstalled: Yes

Superseded patches: None.

Verifying patch installation: 

•	To verify that the patch has been installed on the machine, confirm that the following registry key has been created on the machine: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Exchange Server 5.5\SP5\Q326322
•	To verify the individual files, use the date/time and version information provided in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Updates\Exchange Server 5.5\SP5\Q326322\Filelist

Caveats:

None

Localization:

Localized versions of this patch are available at the locations discussed in "Patch Availability".

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

Top of section