Eudora E-mail Client Integer Overflow May Let Remote IMAP Servers Execute Arbitrary Code on the Client
SecurityTracker Alert ID: 1006773|
SecurityTracker URL: http://securitytracker.com/id/1006773
(Links to External Site)
Updated: Feb 27 2004|
Original Entry Date: May 15 2003
Denial of service via network, Execution of arbitrary code via network, User access via network|
A vulnerability was reported in the Eudora IMAP client software. A remote IMAP server can cause the client to crash or possibly execute arbitrary code.|
When huge literal sizes are allocated, a buffer overflow may occur. If the literal_size is defined as UINT_MAX-1 and the client performs a malloc(literal_size+1) function call, an integer overflow can occur. A similar hole can be triggered if the malloc() is based on a signed integer that becomes negative when the literal_size is specified as '-1'.
A specially crafted server response may be able to cause arbitrary code to be executed on the client.
The vendor has reportedly been notified without response.
A remote server can cause the client to crash. A remote server may be able to cause the client to execute arbitrary code with the privileges of the target user.|
No solution was available at the time of this entry.|
Vendor URL: www.eudora.com/ (Links to External Site)
|Underlying OS: Apple (Legacy "classic" Mac), Windows (Me), Windows (NT), Windows (95), Windows (98), Windows (2000)|
Source Message Contents
Subject: Buffer overflows in multiple IMAP clients|
There's two common vulnerabilities in IMAP clients written with C and C++:
1. Handling huge literal sizes. Many clients do malloc(literal_size+1) and
then read the literal into it. Problem is that if literal_size is
UINT_MAX-1, the +1 overflows it into malloc(0) but server is still allowed
to write UINT_MAX-1 bytes of data there. There may also be similiar
problems if literal size is read into signed integer which causes it to
become negative. Some clients use atoi(), so giving -1 as literal size is
equilevant to giving UINT_MAX-1.
IMAP servers can also be vulnerable to this one if they're not careful.
2. Handling huge mailbox sizes (ie. huge value in EXISTS reply). Many
clients do malloc(messages_count * sizeof(struct message)) and read data
Exploiting these requires that client connects to malicious IMAP server.
Some social engineering (eg. anonymous IMAP access for mailing lists,
announcing "free" IMAP servers, etc.) or man-in-the-middle techniques
should do it.
Using SSL/TLS could prevent MitM, but STARTTLS might not be enough since
client could have already parsed malicious data before beginning the TLS
UW-imapd can also act as IMAP client, allowing user to connect to specified
server. It is disabled for anonymous users, but allowed for everyone else
(even with closedBox, blackBox or restrictBox enabled). So exploiting it
could give you access to the system as the logged in user.
crash: Just crashes because it tries to memcpy() >2GB of data
limited: Values that can be written past buffer are limited
full: Anything can be written past buffer
| 1 | 2 |
c-client | crash | full | Pine, UW-imapd
Evolution | full | - |
kmail | - | - | Nothing obvious at least
Mozilla | full | - (1) |
mutt | - | limited(2) | Balsa also includes mutt's IMAP code
Sylpheed | crash | - |
OE6 | crash(3)| - |
Eudora | full | - | "..0x41414141 .. could not be written"
1) *Maybe* with 64bit systems after you have already sent about 1 billion
messages to Mozilla.
2) Allows writing pointers to malloc()ed data. Maybe also sequentially
growing numbers from 1. I couldn't think of a way to exploit these with
3) Gives quite random behaviour. It seems to be crashing when trying to
copy 4GB of data, but the addresses are always different and sometimes it's
actually trying to read/write data at address sent by client. Anyway,
Microsoft said it was only DoS, and it does seem so.
imap-2002b and Pine 4.53 are vulnerable. imap-2002c is fixed.
Evolution 1.2.4 is vulnerable. 1.3.2 (beta) is fixed.
Mozilla 1.3 and 1.4a are vulnerable. 1.3.1 and 1.4b fixed 1).
mutt 1.4.1 and Balsa 2.0.10 are "vulnerable". Doesn't look exploitable,
don't worry too much about it.
Sylpheed 0.8.11 (including -claws) is "vulnerable". Just a crash, don't
worry about it.
Outlook Express 6.00.2800.1106 was tested to be "vulnerable". Apparently
just a crash. Fix is in next OE service pack.
Eudora 5.2.1 is vulnerable. No replies to bug report I sent.