Yahoo P2P stack reading overflow

[Daniel Atallah]

While looking into coverity CID 732030 (which turned out to be a false
positive as far as I can tell), I found a lack of validation in the
handling of P2P messages for the yahoo protocol.

The issue is that we're assuming the packet length that's in the yahoo
packet is <= the number of bytes that we've read into a 1024 byte
buffer.

This means a malicious client can cause libpurple to read arbitrary
memory locations - I think that the worst of this is a crash, we don't
appear to do any invalid writing.
Not being overly familiar with the yahoo protocol, it isn't entirely
clear to me how this can be triggered - it certainly looks like it can
happen when we're sending a file, but it also looks like it can be
triggered when we're receiving a file or processing some sort of of
other p2p request that comes in through the main server stream.

There is an additional bug that's corrected in the attached patch with
dealing with malformed/unexpected packets, but that's more of a
correctness thing than a security issue.

-D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: yahoo_p2p.patch
Type: application/octet-stream
Size: 2812 bytes
Desc: not available
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20130224/a56725d6/attachment.obj>