Re: mail-client/claws-mail-3.13.1: Stack Overflow - CVE needed?

[Ben Hutchings <ben () decadent org uk>]

On Mon, 2015-12-21 at 21:31 -0500, cve-assign () mitre org wrote:
> > https://bugs.gentoo.org/show_bug.cgi?id=569010
>
> > http://www.thewildbeast.co.uk/claws-mail/bugzilla/show_bug.cgi?id=3557
>
> > > So in codeconv.c there is a function for japanese character set
> > > conversion called conv_jistoeuc(). There is no bounds checking on the
> > > output buffer, which is created on the stack with alloca().
>
> > > http://git.claws-mail.org/?p=claws.git;a=commit;h=d390fa07f5548f3173dd9cc13b233db5ce934c82
> > >
> > > conv_jistoeuc
> > > conv_euctojis
> > > conv_sjistoeuc
>
> The original discoverer found a conv_jistoeuc issue, and then the
> vendor apparently also found conv_euctojis and conv_sjistoeuc issues.
> However, we don't see an indication that these issues arose in
> independent ways. (Also, there is no vendor statement that
> conv_euctojis or conv_sjistoeuc is exploitable.) It seems best to
> assign CVE-2015-8614 to the combination of the conv_jistoeuc,
> conv_euctojis, and conv_sjistoeuc issues.
[...]

Note that two of the bounds checks added in that commit are incorrect:

1. In conv_jistoeuc() the check uses > rather than <, which causes all
   conversions to return an empty string.  This is presumably not a
   security issue, but is a regression.

3. In conv_euctojis() the comparison is with outlen - 3, but each pass
   through the loop uses up to 5 bytes and the rest of the function may
   add another 4 bytes.  The comparison should presumably be 
   '<= outlen - 9' or equivalently '< outlen - 8'.

The first check is fixed by a later commit:
http://git.claws-mail.org/?p=claws.git;a=commitdiff;h=e3ffcb455e0376053451ce968e6c71ef37708222

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken.

Attachment: signature.asc
Description: This is a digitally signed message part