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