Re: CVE Request: jabberd remote information disclosure

[Thijs Alkemade <me () thijsalkema de>]

On 23 feb. 2015, at 08:41, cve-assign () mitre org wrote:

> Signed PGP part
> > When parsing a JID, jabberd2 version 2.3.2 and below truncate the data
> > but do not verify whether the result is valid UTF8 before passing it
> > to libidn. If the data ends with an unterminated multi-byte UTF8
> > sequence then libidn may copy data past the buffer into the result.
>
> > https://github.com/jabberd2/jabberd2/issues/85
>
> > the stringprep functions from libidn require the input to be valid UTF8
>
> > The libidn documentation claims "This function will not read or write
> > to characters outside that size." about the length of the buffer that
> > needs to be specified, but this is not true,
>
> We think this requires one CVE ID for jabberd2 and one CVE ID for
> libidn, because the issues could be addressed independently. For
> example, if only jabberd2 is changed, then libidn still has an
> out-of-bounds read issue with input from other programs. If only
> libidn were changed and (for example) the change was to fail on
> invalid UTF-8 data, then that would have a DoS effect on jabberd2.
>
> Did you believe that libidn does not have a vulnerability on
> its own?

I had not considered whether libidn has a vulnerability on its own, because
the libidn documentation is pretty clear that the input must already be UTF-8
encoded. However, as the security implications of not abiding by the API are
unexpectedly severe, I think assigning it a CVE makes sense.

Thanks,
Thijs Alkemade

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail