Home    |    View Topics    |    Search    |    Contact Us    |   



Category:   Application (E-mail Client)  >   Mutt Vendors:
Mutt Buffer Overflow in 'handler.c' May Let Remote Users Execute Arbitrary Code
SecurityTracker Alert ID:  1014729
SecurityTracker URL:
CVE Reference:   CVE-2005-2642   (Links to External Site)
Updated:  Jun 8 2008
Original Entry Date:  Aug 18 2005
Impact:   Execution of arbitrary code via network, User access via network

Version(s): 1.4.2 (stable) and 1.5.9 (snapshot)
Description:   A buffer overflow vulnerability was reported in Mutt. A remote user can cause arbitrary code to be executed on the target user's sytsem.

The mutt_decode_xbit() function in 'handler.c' contains a buffer overflow. A remote user can send a specially crafted e-mail message to trigger an overflow of the 'bufi' variable and potentially execute arbitrary code. Some other similar functions may also be affected.

A demonstration exploit mailbox is available at:

The vendor was notified on August 11, 2005.

Impact:   A remote user can cause arbitrary code to be executed on the target user's system with the privileges of the target user.
Solution:   No solution was available at the time of this entry.
Vendor URL: (Links to External Site)
Cause:   Boundary error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   None.

 Source Message Contents

Subject:  [Full-disclosure] mutt buffer overflow

There is a buffer overflow in mutt found thanks to ProPolice, which may
allow an attacker to execute code by sending a maliciously crafted email.
All latest versions appear affected.  Mutt is an e-mail client
that sucks less according to the headline on

The problem is in the mutt attachment/encoding/decoding functions,
specifically handler.c:mutt_decode_xbit() and the buffer
bufi[BUFI_SIZE].  The variable 'l' is used as a counter to reference a
position in the buffer and under certain circumstances its value can be
manipulated and becomes much larger than the size of this buffer, thus
overwriting other memory with many possible consequences.  This counter
should never exceed the size and I believe the logic in the
convert_to_state() function is supposed to reset it to 0, however
there is a flaw - I have included a possible fix but I'm not sure
it's the 100% correct fix and there seem to be no developers
willing to fix this so far.  There are other functions affected in
the same way due to copy/paste, such as mutt_decode_uuencoded() that
this patch should also fix.

There is a sample mailbox at which
observes the problem - the last message causes data to be written to
addresses bufi[~1300] and above, when the size is 1000 (BUFI_SIZE) -
this can easily be seen by monitoring the counter from gdb or adding
printf's.  Since this and other such experiments cause the propolice
canary to get damaged (being right next to the return address), it
seems very likely for this to be exploitable, except on system such
as OpenBSD that include ProPolice by default.

Vendor response:  A bug report was submitted a week ago on August 11,
bug report #2033 and there has been no response.  The bug seems to exist
in both the latest stable and snapshot releases.  In fact a little
searching around seems it has been previously reported, but ignored
as unimportant, like seen in the Feb 26 message "Occasionally fatal bug
in handler.c?",

Here is a possible fix

--- handler.c.orig	Tue Mar 26 02:49:51 2002
+++ handler.c	Wed Aug 10 16:55:02 2005
@@ -95,7 +95,7 @@ static void convert_to_state(iconv_t cd,
-  if (cd == (iconv_t)(-1))
+  if (cd == (iconv_t)(-1) || *l >= BUFI_SIZE)
     state_prefix_put (bufi, *l, s);
     *l = 0;

Peter Valchev <>
Full-Disclosure - We believe in it.
Hosted and sponsored by Secunia -


Go to the Top of This SecurityTracker Archive Page

Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2021, LLC