** Please note that this issue is confidential and no information should be disclosed until it is made public, see "Whiteboard" for a date ** Libpurple <= 2.5.8 (Pidgin <= 2.5.8 - Adium <= 1.3.5) ===================================================== Vulnerability: ============== Type: Arbitrary Write Remotely Exploitable: Yes Access Vector: Network exploitable, No victim interaction required Authentication: Not required to exploit Impact Type: Allows unauthorized disclosure of information, unauthorized modification, disruption of service, arbitrary code execution. Technical description / Proof of concept code: ============================================== The flaw exists within the function msn_slplink_process_msg() of Libpurple <= 2.5.8, which fails to properly validate an offset value specified in the MSNSLP packet. This affects at least two widely used products: Pidgin <= 2.5.8 [1] and Adium <= 1.3.5 [2]. According to [3], Libpurple is also used by: - Apollo IM - IM application for the iPhone and iPod Touch. - EQO - An IM program for mobile phones. - Finch - A text-based IM program that works well in Linux and other Unixes. - Instantbird - A graphical IM program based on Mozilla's XUL framework. - Meebo - A web-based IM program. - Palm - Maybe used in the messenger on the Palm Pre? - Telepathy-Haze - A connection manager for the Telepathy IM framework All of them must be considered vulnerable. If the victim has it's privacy settings set to "everyone can contact me", the victim doesn't even has to be in the attacker's contact list. Otherwise that's the only requirement for exploitation. No victim interaction is required. By providing a specific value, an attacker can write an arbitrary address with controlled data, resulting in arbitrary code execution. Previous patches ================ The vulnerability was already reported in CVE-2009-1376 and CVE-2008-2927. CVE-2008-2927 added some bounds checking in msn_slplink_process_msg(), specifically: [code] if (G_MAXSIZE - len < offset || (offset + len) > slpmsg->size) { .. discard packet .. } else { .. vulnerable memcpy .. } [/code] CVE-2009-1376 demonstrates that this can be exploited. The idea of the patch for CVE-2009-1376 was to fix a casting error, where an unsigned 64bits integer was casted to a unsigned 32 bits integer in this line: [code] declaration of offset; ... offset = msg->msnslp_header.offset; [/code] The declaration of offset was changed from <b>gsize</b> to <b>guint64</b> in 2.5.8. This approach is clearly not enough, we found that providing a different size/offset values the call to memcpy() can still be reached with almost any value. The first PoC we constructed to trigger this vulnerability was fixed by the patch introduced in Libpurple 2.5.6, but by working on it a little more, we triggered the bug again in Libpurple 2.5.8. We conclude that the fix is incomplete. Exploitation of Libpurple 2.5.8 =============================== The attack consists in sending two consecutive MSNSLP messages. The first one is used to store a slpmsg with our session id, and the second one to trigger the vulnerability. Our goal is to reach the memcpy in msn_slplink_process_msg(), we need to construct a MSNSLP message with offset != 0 (as this value will be the dst of the vulnerable memcpy()). As the offset will be != 0, the first problem arises when a call to msn_slplink_message_find() returns NULL: [code] if (offset == 0) { .. construct a new slpmsg .. } else { slpmsg = msn_slplink_message_find(slplink, msg->msnslp_header.session_id, msg->msnslp_header.id); } if (slpmsg == NULL) { /* Probably the transfer was canceled */ purple_debug_error("msn", "Couldn't find slpmsg\n"); return; } [/code] So, slpmsg must be != NULL. And this is exactly why this is a two-message attack. We need to send a first MSNSLP message, with an offset == 0, that constructs a slpmsg object, so Libpurple will store it. The second MSNSLP message will have an offset value != 0, but as Libpurple stored our first MSNSLP message, the call to msn_slplink_message_find() will effectively return our previous object, instead of NULL. So we reach: [code] if (slpmsg->fp) { /* fseek(slpmsg->fp, offset, SEEK_SET); */ len = fwrite(data, 1, len, slpmsg->fp); } else if (slpmsg->size) { if (G_MAXSIZE - len < offset || (offset + len) > slpmsg->size) { purple_debug_error("msn", "Oversized slpmsg - msgsize=%lld offset= %" G_GSIZE_FORMAT " len=%" G_GSIZE_FORMAT "\n", slpmsg->size, offset, len); g_return_if_reached(); } else memcpy(slpmsg->buffer + offset, data, len); } [/code] For example, if we construct our first MSNSLP message so it has a size of 0x01ffffff, and the second one (which is being processed and it's offset is assigned to the offset variable) has an offset of an arbitrary value lower than (0x01ffffff - len), then conditions for arbitrary write are met. At the end, we reach memcpy() with an offset of any value < (0x01ffffff - len) and the buffer pointing to 0. This means that we can write the contents of data in an arbitrary location < (0x01ffffff - len), which allows arbitrary code execution in almost any platform. References ========== [1] http://www.pidgin.im/ [2] http://adium.im/ [3] http://developer.pidgin.im/wiki/WhatIsLibpurple
I have no embargo date on this issue. Olivier, if you like you can prepare an ebuild and we'll perform prestabling on this bug. As usual, no commits while the embargo lasts.
Created attachment 201303 [details, diff] fix_for_msn_remote_crash.diff
Created attachment 201337 [details] ebuild Attached ebuild which applies patch. It has the same keywords as 2.5.8 as you'll all have it tested so we can commit it straight to stable when its made public. It seems to work fine on amd64.
Btw, this should be B1, its a "remote active compromise", one can remotely execute arbritrary code.
Arch Security Liaisons, please test the attached ebuild and report it stable on this bug: =net-im/pidgin-2.5.8-r1 Target keywords : "alpha amd64 hppa ia64 ppc ppc64 sparc x86" CC'ing current Liaisons: alpha : armin76, klausman amd64 : keytoaster, chainsaw hppa : jer ppc : josejx, ranger ppc64 : josejx, ranger x86 : fauli, maekke
Good on x86.
Looks fine on amd64.
HPPA is OK.
now public
*** Bug 281958 has been marked as a duplicate of this bug. ***
now public and/or bump to 2.5.9
Pidgin 2.5.9 is in the tree. The liaisons have been replaced with the full arch teams since its now stable. It has an extra bugfix when sending files with NULL names (whatever that is), so I guess arch teams should test/stable it asap.
Arches, please test and mark stable: =net-im/pidgin-2.5.9 Target keywords : "alpha amd64 hppa ia64 ppc ppc64 sparc x86"
x86 stable
Stable for HPPA.
CVE-2009-2694 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2009-2694): The msn_slplink_process_msg function in libpurple/protocols/msn/slplink.c in libpurple, as used in Pidgin (formerly Gaim) before 2.5.9 and Adium 1.3.5 and earlier, allows remote attackers to execute arbitrary code or cause a denial of service (memory corruption and application crash) by sending multiple crafted SLP (aka MSNSLP) messages to trigger an overwrite of an arbitrary memory location. NOTE: this issue reportedly exists because of an incomplete fix for CVE-2009-1376.
amd64 stable
ppc stable
alpha/ia64/sparc stable
ppc64 done
GLSA request filed.
Olivier/net-im: Please remove vulnerable versions.
version 2.5.8 cleaned up
GLSA 200910-02, thanks everyone, sorry about the delay.
