Opened 11 years ago

Closed 11 years ago

#6246 closed patch (fixed)

MSN receive crash fix after failed file open

Reported by: sbrabec Owned by: khc
Milestone: Component: MSN
Version: 2.4.3 Keywords: file transfer
Cc:

Description

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

In case, if destination file open fails for any reason, the whole xfer structure was already unref'ed in purple_xfer_cancel_local().

Attached patch fixes only the crash on the receiving side and not other aspects of this error:

  • Sending side thinks, that transfer succeeded.
  • Creating a private copy of the file descriptor may be sub-optimal - libpurple provides its own file writing callback.

References:

CVE-2008-2955

BUGTRAQ:20080626 Pidgin 2.4.1 Vulnerability

FRSIRT:ADV-2008-1947

SECUNIA:30881

Attachments (2)

pidgin-msn-xfer-fail.patch (1.2 KB) - added by sbrabec 11 years ago.
pidgin-msn-xfer-fail.patch
pidgin-msn-xfer-fail.2.patch (3.1 KB) - added by mmarek 11 years ago.
updated patch

Download all attachments as: .zip

Change History (11)

Changed 11 years ago by sbrabec

pidgin-msn-xfer-fail.patch

comment:1 Changed 11 years ago by Sim-on

  • Type changed from defect to patch

comment:2 Changed 11 years ago by sbrabec

The fix is far from being complete. After unexpected transfer cancellation, referred structures are already freed. Additionally, some parts of these structures are not freed once, but two or three times.

I am still debugging it with only partial result.

comment:3 Changed 11 years ago by khc

other than the original description, are you aware of any other cases where unexpected transfer cancellation causes a problem?

comment:4 Changed 11 years ago by khc@…

(In 3008474548ddd234f222ed5a0be3066e2ea0da0b):
take an extra reference to PurpleXfer? so we can check whether the whole thing went away. I haven't tested this because it's late, but it shouldn't break things or at least shouldn't make things worse.

It would be great if someone can test this and let me know.

References #6246

Changed 11 years ago by mmarek

updated patch

comment:5 Changed 11 years ago by mmarek

I posted another patch on devel@ in the meantime (patching msnp9/, see previous comment). I'll try the one commited to msn/

comment:6 Changed 11 years ago by mmarek

I get "Our protocol is not supported by the server." when building pidgin with --enable-msnp14. The account settings are like this:

<settings>
  <setting name='use-global-buddyicon' type='bool'>1</setting>
  <setting name='check-mail' type='bool'>0</setting>
  <setting name='http_method_server' type='string'>gateway.messenger.hotmail.com</setting>
  <setting name='server' type='string'>muser.messenger.hotmail.com</setting>
  <setting name='http_method' type='bool'>0</setting>
  <setting name='buddy_icon_timestamp' type='int'>0</setting>
  <setting name='port' type='int'>1863</setting>
  <setting name='custom_smileys' type='bool'>1</setting>
</settings>

Are there any special steps needed to test msnp14? I'll try to port your patch to msnp9 and report the results.

comment:7 Changed 11 years ago by mmarek

Great, the patch from 3008474548ddd234f222ed5a0be3066e2ea0da0b applied to msn/ seems to do the trick as well.

comment:8 Changed 11 years ago by Dimmuxx

msnp14 won't be used and doesn't work any longer but msnp15 works and will be enabled by default in 2.5.0.

Great that the patch work. :)

comment:9 Changed 11 years ago by khc

  • Resolution set to fixed
  • Status changed from new to closed

thanks for testing!

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!