Jabber OOB Transfer security issue

[Matt Jones]

Hey Daniel,

I didn't investigate this one further than what my writeup said. Why
wouldn't it be an avenue, can you elaborate a tiny bit?

Thanks,

Matt

On Sun, Nov 24, 2013 at 10:12 AM, Daniel Atallah
<daniel.atallah at gmail.com> wrote:
>
> 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