Ipswitch IMail LDAP Daemon Buffer Overflow Lets Remote Users Execute Arbitrary Code
SecurityTracker Alert ID: 1009091|
SecurityTracker URL: http://securitytracker.com/id/1009091
(Links to External Site)
Date: Feb 17 2004
Execution of arbitrary code via network, Root access via network|
Fix Available: Yes Vendor Confirmed: Yes |
Version(s): 8.03 (iLDAP.exe ver. 188.8.131.52)|
iDEFENSE reported a buffer overflow vulnerability in the Ipswitch IMail Server in the LDAP daemon. A remote user can execute arbitrary code.|
It is reported that a remote user can connect to the LDAP daemon and send a specially crafted message to trigger the buffer overflow and execute arbitrary code with administrator privileges.
The software reportedly does not properly check the bounds of user-supplied values before copying the user-supplied data. A remote user can overwrite the address of the Global Exception Handler to ultimately execute arbitrary code, the report said.
iDEFENSE confirms that exploitation can be achieved on both Windows 2000 and XP platforms.
The vendor was reportedly notified on February 2, 2004.
A remote user can execute arbitrary code with administrator privileges.|
The vendor has issued a fix in 8.05 Hotfix 2, available at:|
Vendor URL: www.ipswitch.com/support/imail/releases/imail_professional/im805HF2.html (Links to External Site)
|Underlying OS: Windows (NT), Windows (2000), Windows (2003), Windows (XP)|
Source Message Contents
Subject: iDEFENSE Security Advisory 02.17.04: Ipswitch IMail LDAP Daemon Remote|
iDEFENSE Security Advisory 02.17.04
Ipswitch IMail LDAP Daemon Remote Buffer Overflow
February 17, 2004
Ipswitch IMail server is a Windows based messaging solution with a
customer base of over 53 million users. More information about the
application is available at
Exploitation of a remote buffer overflow within the LDAP daemon of
Ipswitch IMAIL Server allows attackers to execute arbitrary code under
administrator privileges. LDAP messages are comprised of various tags
consisting of an identifier, a length and the content. An integer is
represented in LDAP by the identifier byte 0x02, followed by the length
of the integer in bytes. This is followed by the actual integer itself.
As an example the following tag: 0x02 0x03 0x0A 0x25 0xBD represents the
integer 665,501 (0xA25BD). The problem exists due to insufficient bounds
checking upon copying of user supplied data with large tag lengths to a
stack based buffer. The following assembly instruction can be abused to
overwrite memory addresses as offsets from the current frame pointer
because the attacker has control over ecx and var_4 at the time of
.text:00401188 mov byte ptr [ebp+ecx+var_4], dl
An attacker can utilize this to overwrite the address of the Global
Exception Handler, which can be found at a static distance from the
frame pointer. Overwriting this address with that of a memory location
containing a JMP/CALL ebx instruction (in Windows 2000)
or a POP xxx POP xxx RET instruction (in Windows XP), allows the
attacker to redirect the flow of control to his or her own supplied
Successful exploitation allows unauthenticated remote attackers to
execute arbitrary code under administrator privileges. Exploitation is
possible across both Windows 2000 and XP platforms. However, it requires
minor changes in order to work.
iDEFENSE has confirmed that the LDAP daemon (iLDAP.exe ver. 184.108.40.206)
shipping with IMail Server version 8.03 is vulnerable. It us suspected
that earlier versions are vulnerable as well.
Disable or firewall the LDAP service (TCP port 389) if unneeded.
Successful exploitation can cause the LDAP daemon to crash and will
require a restart in order to resume normal operation.
VII. VENDOR RESPONSE
"Testing has completed their review of 8.05 Hotfix 2 and we are ready to
The fix will be available for download at:
VIII. CVE INFORMATION
A Mitre Corp. Common Vulnerabilities and Exposures (CVE) number has not
been assigned yet.
IX. DISCLOSURE TIMELINE
October 31, 2003 Exploit acquired by iDEFENSE
February 2, 2004 Initial vendor notification
February 3, 2004 iDEFENSE clients notified
February 3, 2004 Vendor response received
February 17, 2004 Coordinated public disclosure