Ipswitch IMail Server Reply-To BO

The Ipswitch IMail Server is a mail server geared towards medium to large size organizations. It implements the POP3, IMAP4, and SMTP protocols. The SMTP server module is installed and started in a default installation.

The SMTP protocol defines a set of commands used to exchange email messages between network connected hosts. The full SMTP protocol specification is outlined in RFC 821. SMTP commands are composed of ASCII strings separated by the end of line byte sequence 0x0d0a (CRLF). In a standard SMTP session, after the TCP connection is opened, there is normally a handshake process between the client and server. After successful connection has been established, the client will either send an email to an account on the SMTP server or will use the server to relay the message to its destination.

An SMTP email message consists of a header and a message body. The header consists of several lines defining numerous aspects of the email such as the source and destination addresses. The body of the message begins after an empty line following the header. Each header line is composed of a field name, followed by a colon character ":", further followed by the field value, terminated by CRLF. For example:

From:  To:  Subject: test email Reply-To:  Content-Type: text/plain;

Some of the header fields specified by the standard are listed below:

Bcc Cc Date From Received Reply-To Subject To X-headers

A buffer overflow vulnerability exists in the Ipswitch IMail server. The vulnerability is due to a boundary error in the processing of the Reply-To SMTP header. If multiple Reply-To headers exist in a message, the vulnerable code will concatenate them into a single string. This string will then be copied into a fixed size stack buffer without any prior checks of the final string's length. If the length of the concatenated Reply-To header is greater than the size of the allocated buffer, the string copy operation will result in user supplied data overrunning the provided buffer. This will lead to corruption of sensitive stack data such as the function return addresses. Unauthenticated attackers may exploit this vulnerability by supplying a crafted SMTP message with multiple, long Reply-To headers. Successful exploitation may allow arbitrary code to be injected and executed with the privileges of the server process.

SonicWall has established IPS signatures in place to proactively detect and block attacks of these types. The following SMTP signatures are effectively blocking SMTP related attacks by detecting common shellcode transfers:

• 4120 - Generic SMTP Attack Attempt
• 5470 - Generic SMTP Shellcode Exploit

SonicWALL has additional generic signatures that encompass multiple protocols, including SMTP, which are not protocol specific. These signatures are also effective in proactively blocking attacks against SMTP servers.