Security Bulletin
Microsoft Security Bulletin MS02-037 - Moderate
Server Response To SMTP Client EHLO Command Results In Buffer Overrun (Q326322)
Published: July 24, 2002 | Updated: July 25, 2002
Version: 1.1
Originally posted: July 24, 2002
Summary
Who should read this bulletin: System administrators using Microsoft® Exchange Server 5.5.
Impact of vulnerability: Ability to run arbitrary code
Maximum Severity Rating: Moderate
Recommendation: System administrators should consider applying the patch.
Affected Software:
- Microsoft Exchange Server 5.5
General Information
Technical details
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:
- <Exchange server ID> is the fully-qualified domain name (FQDN) of the Exchange server
- <Connecting server ID> is either the FQDN or the IP address of the server that initiated the connection. The FQDN would be used if the Exchange5.5 IMC is able to resolve this information through a reverse DNS lookup; the IP address would be used if a reverse DNS lookup was not possible or failed to resolve the connecting servers IP address.
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:
- Creating an environment in which the IMC's reverse DNS lookup would not only succeed but also result in the buffer being overrun would be difficult. The attacker could set up a rogue DNS server and manually populate the bogus FQDN information on it, but in this would require that the attacker have some means of forcing the IMC to consult the rogue DNS server when performing the reverse DNS lookup.
- The IMC can be disabled for cases where SMTP support is not needed. If this has been done, the vulnerability could not be exploited.
- Customers can disable Reverse DNS lookup on EHLO by setting a registry key as defined in Q190026. The vulnerability could not be exploited on a system configured in such a way.
- If the buffer overrun caused the IMC to fail, normal service could be restored by restarting the Exchange 5.5 IMC service.
Severity Rating:
| Internet Servers | Intranet Servers | Client Systems | |
|---|---|---|---|
| Exchange 5.5 SP4 | Moderate | Moderate | None |
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.
Frequently asked questions
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:
- Server 1 establishes a connection to Server 2.
- Server 2 sends a "banner".
- Server 1 sends an EHLO, so that it can determine what SMTP extensions Server 2 supports.
- If Server 2 supports EHLO, Server 2 responds to the EHLO by sending a "Hello", identifying itself and Server 1 as the two participants in the connection and a listing all of the Server Extensions it supports.
- Server 1 begins levying requests upon Server 2.
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:
- The IMC could determine the other server's FQDN.
- The length of the IMC's own FQDN, plus that of the other server's FQDN, exceeded a particular value.
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.
Patch availability
Download locations for this patch
Microsoft Exchange 5.5 Service Pack 4:
Additional information about 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
Other information:
Acknowledgments
Microsoft thanks Dan Ingevaldson of Internet Security Systems for reporting this issue to us and working with us to protect customers.
Support:
- Microsoft Knowledge Base article Q326322 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.
Disclaimer:
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.
Revisions:
- V1.0 (July 24, 2002): Bulletin Created.
- V1.1 (July 25, 2002): Changed to indicate that patch can be uninstalled.
Built at 2014-04-18T13:49:36Z-07:00