TechNet Home >  Security >  Bulletins

   Microsoft Security Bulletin MS02-037
                                                            [Print] Print

  Server Response To SMTP Client EHLO Command Results In Buffer Overrun
  (Q326322)

  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

  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         Intranet
                             Servers          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:

         1. Server 1 establishes a connection to Server 2.
         2. Server 2 sends a "banner".
         3. Server 1 sends an EHLO, so that it can determine what
            SMTP extensions Server 2 supports.
         4. 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.
         5. 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:
            http://www.microsoft.com/Downloads/Release.asp?ReleaseID=40666

  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.

  Contact Us   |   E-mail this Page   |   TechNet Newsletter

  © 2002 Microsoft Corporation. All rights reserved.     Terms of Use    Privacy Statement    Accessibility