Re: [Mutt] #2033: buffer overflow in attachment decoding function
#2033: buffer overflow in attachment decoding function
Changes (by brendan):
* priority: critical => major
Old description:
> {{{
> There is a potentially serious buffer overflow in
> mutt-1.4.2/handler.c:mutt_decode_xbit() as well as the uuencode and other
> attachment decoding functions, discovered thanks to ProPolice (included
> by default on OpenBSD).
>
> The 'bufi' variable in mutt_decode_xbit is of size BUFI_SIZE and under
> certain conditions the counter used to write to it increases past its
> bounds, then data is written there (bad). Basically there is a check on
> handler.c:142 which calls convert_to_state() in that case which is
> supposed to reset this variable to 0 from my understanding and never
> allow this to happen, however there is a flaw in the logic. Under the
> failure scenario, 'l' is greater than BUFI_SIZE upon return from this
> function.
>
> A link to a sample mailbox with which this can be reproduced can be found
> below - the last message in it causes this to happen upon viewing (it is
> all spam), specifically appears to be caused by some koir-8 characters.
> A possible fix also included here. This is likely exploitable on systems
> that do not have propolice.
> >How-To-Repeat:
> Download http://sightly.net/peter/tmp/mutt-bug.fo
> and mutt -f mutt-bug, then view the last message.
> >Fix:
> See attached "patch-handler_c"
> }}}
New description:
There is a potentially serious buffer overflow in
mutt-1.4.2/handler.c:mutt_decode_xbit() as well as the uuencode and other
attachment decoding functions, discovered thanks to ProPolice (included by
default on OpenBSD).
The 'bufi' variable in mutt_decode_xbit is of size BUFI_SIZE and under
certain conditions the counter used to write to it increases past its
bounds, then data is written there (bad). Basically there is a check on
handler.c:142 which calls convert_to_state() in that case which is
supposed to reset this variable to 0 from my understanding and never allow
this to happen, however there is a flaw in the logic. Under the failure
scenario, 'l' is greater than BUFI_SIZE upon return from this function.
A link to a sample mailbox with which this can be reproduced can be found
below - the last message in it causes this to happen upon viewing (it is
all spam), specifically appears to be caused by some koir-8 characters. A
possible fix also included here. This is likely exploitable on systems
that do not have propolice.
>How-To-Repeat:
Download http://sightly.net/peter/tmp/mutt-bug.fo
and mutt -f mutt-bug, then view the last message.
>Fix:
See attached "patch-handler_c"
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2033#comment:4>