Jabber OOB Transfer security issue

Daniel Atallah daniel.atallah at gmail.com
Sat Nov 23 18:12:12 EST 2013


On Wed, Sep 18, 2013 at 9:28 PM, Matt Jones <matt at volvent.org> wrote:
>
> Hi,
>
> Please see below another issue related to Jabber OOB transfers.
>
> Thanks,
>
> Matt
>
> Summary:
>
> jabber_oob_xfer_read() is susceptible to a memory corruption issue due
> to dangerous handling of the Content-Length HTTP header.

<SNIP>

> The function reads a content-length parameter from the client [1] and
> prepares reading data.  The issue is that it's using a signed integer
> for the Content-Length header [2], which is a classic issue that has
> been present in many HTTP implementations in the past that parse this
> particular header.  This dangerous construct commonly leads to memory
> corruption as negative content lengths will affect memory related
> operations and/or arithmetic.
>
> Recommendation
>
> It is recommended to change size as an unsigned integer and also
> validate that it's within a reasonable range.

I looked into this in more detail and I agree with Thijs' analysis - it's
not an avenue for memory corruption.

I just pushed the following commit to clean up the parsing slightly:
https://hg.pidgin.im/pidgin/main/rev/33e652e01e49

The code in question was improved in
https://hg.pidgin.im/pidgin/main/diff/d5e9c888ccd7/libpurple/protocols/jabber/oob.c

The code in question was also completely revamped in the 3.0.0 codebase:
https://hg.pidgin.im/pidgin/main/diff/8df870b218ca/libpurple/protocols/jabber/oob.c

Thanks again for the report.

-D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20131123/d6c616ef/attachment-0001.html>


More information about the security mailing list