Possible libpurple vulnerability in multiple prpls

[Elliott Sales de Andrade]

Hi there,

I think I have a potentially exploitable crash here, and I'm trying to
determine whether it's going to be requiring a CVE ID. I'm holding off on
applying the fix until this is determined. The exploit requires the user to
accept a file transfer and then crashes because of passing NULL to
g_filename_to_utf8.

Specifically, most prpls call purple_xfer_request and assume that they
correctly set a filename already. However, through specially-crafted
messages, this is not always the case. Once the user accepts, libpurple is
left with a NULL pointer which it uses to 1) attempt to open the input file
(in purple_xfer_start), and failing to do so: 2) attempt to print a failure
message, requiring: 3) a call to g_filename_to_utf8, which crashes.

I am able to reproduce this in MSN and XMPP. Bonjour appears susceptible as
well based on the code, but I have not tested it. Yahoo appears to be okay
from the code, but I can't test. I don't really know about the other prpls.
If you want to check, look for purple_xfer_request and the
purple_xfer_set_filename call just before it. If there's absolutely no way
that the filename is NULL in that call, then your prpl is safe.

More generally, we may want to add a better check in purple_xfer_start. But
before this, I would like to know which prpls had this problem.

Elliott
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/packagers/attachments/20090815/00e241a1/attachment.htm>