Jabber OOB Transfer security issue
matt at volvent.org
Sat Nov 23 18:45:16 EST 2013
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?
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:
>> Please see below another issue related to Jabber OOB transfers.
>> jabber_oob_xfer_read() is susceptible to a memory corruption issue due
>> to dangerous handling of the Content-Length HTTP header.
>> The function reads a content-length parameter from the client  and
>> prepares reading data. The issue is that it's using a signed integer
>> for the Content-Length header , 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.
>> 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:
> The code in question was improved in
> The code in question was also completely revamped in the 3.0.0 codebase:
> Thanks again for the report.
More information about the security