full-disclosure - mutt buffer overflow

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <20050818085732.GA11016@beryl.sightly.net>
Date: Thu Aug 18 10:11:41 2005
From: pvalchev at sightly.net (Peter Valchev)
Subject: mutt buffer overflow

Summary/Impact:
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 http://www.mutt.org/

Details:
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 http://sightly.net/peter/tmp/mutt-bug 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?", http://blog.gmane.org/gmane.mail.mutt.devel/day=20030226

Fix:
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,
     return;
   }

-  if (cd == (iconv_t)(-1))
+  if (cd == (iconv_t)(-1) || *l >= BUFI_SIZE)
   {
     state_prefix_put (bufi, *l, s);
     *l = 0;

--
Peter Valchev <pvalchev@...htly.net>