ZDI-CAN-338: libpurple MSN Protocol SLP Message Heap Overflow Vulnerability

[Mark Doliner]

On Thu, 26 Jun 2008 11:43:25 -0500, Richard Laager wrote
> On Tue, 2008-05-27 at 10:01 -0700, zdi-disclosures at 3com.com wrote:
> > The bug is in libpurple/protocols/msn/slplink.c in the
> > msn_slplink_process_msg function:
> >
> > void msn_slplink_process_msg(MsnSlpLink *slplink, MsnMessage *msg){
> >    gsize offset;    
> > ...
> >    offset = msg->msnslp_header.offset; [ 1 ]
> > ...
> >        slpmsg->size = msg->msnslp_header.total_size;
> > ...
> >            slpmsg->buffer = g_try_malloc(slpmsg->size);
> > ...
> >        if ((offset + len) > slpmsg->size) [ 2 ]
> >        {
> >            purple_debug_error("msn", "Oversized slpmsg\n");
> >            g_return_if_reached();
> >        }
> >        else
> >            memcpy(slpmsg->buffer + offset, data, len); [ 3 ]
> >
> > If offset = -1 * len, then the check at [ 2 ] will pass because offset
> > + len = 0.  The memcpy at [ 3 ] will then write (-1 * len) bytes
> > *before* the memory allocated to slpmsg->buffer.  This allows you to
> > overwrite malloc_chunk structures or application structures which are
> > within len bytes of slpmsg->buffer.
> 
> Another developer noticed this:
> offset and len are both of type gsize, which is unsigned. Therefore,
> neighter can be negative, so this shouldn't be possible.
> 
> Are we missing something?

You're right, neither offset nor len can be negative.  But they CAN be very
large, and if they add together to become greater than the largest possible
64-bit (or 32-bit depending on the architecture) integer then the value wraps
around to 0.

I think the vulnerability is valid, but I think our fix needs to make sure
we're not wrapping back to 0.

-Mark