fix for MSN file transfer crash (CVE-2008-2955)

Stanislav Brabec sbrabec at
Mon Jul 7 06:48:49 EDT 2008


I got a report on an MSN invalid file name triggered crash of receiving

As I did not found a fix nor a bug report anywhere in the pidgin bug
tracker, I tried to fix it.

Here is my attempt:

I am not a pidgin expert, so the fix may be incorrect, but it fixed the
crash for me.

File receive in msn_slplink_process_msg() calls purple_xfer_start() and
then it copies dest_fp file descriptor to a private structure without
further checks checking.

In case, if destination file open fails for any reason,
purple_xfer_start() calls purple_xfer_cancel_local(), and it 
calls purple_xfer_unref() on the whole xfer structure.

Subsequent xfer->dest_fp then tries to access released memory.

I am not sure, why MSN code clones file descriptor to its own structures
- libpurple provides its own file writing callback.

It seems to have lower severity than reported - malicious sender can
cause failure only by choosing invalid (e. g. too long) file name.

the problem can be triggered even when sending from pidgin to pidgin -
file name suggested in the PoC has the maximal length on the sender
side, but maximal length + 1 on the receiving side. I did not searched
in deep, why it is one byte longer - maybe it's caused by glib filename
encoding code.

BUGTRAQ:20080626 Pidgin
2.4.1 Vulnerability

Best Regards / S pozdravem,

Stanislav Brabec
software developer
SUSE LINUX, s. r. o.                          e-mail: sbrabec at
Lihovarská 1060/12           tel: +420 284 028 966, +49 911 740538747
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                          

More information about the Packagers mailing list