|
|
|
|
| |
Credit:
The information has been provided by Core Security Technologies.
The original article can be found at: http://www.coresecurity.com/content/libpurple-arbitrary-write
|
| |
Vulnerable Systems:
* Gaim >= 0.79
* Libpurple <= 2.5.8 (Pidgin <= 2.5.8 and Adium <= 1.3.5)
* Other Libpurple frontends such as Finch might be vulnerable as well.
Immune Systems:
* Libpurple >= 2.6.0 (Pidgin >= 2.6.0)
A remote arbitrary-code-execution vulnerability has been found in Libpurple (used by Pidgin and Adium instant messaging clients, among others), which can be triggered by a remote attacker by sending a specially crafted MSNSLP packet with invalid data to the client through the MSN server. No victim interaction is required, and the attacker is not required to be in the victim's buddy list (under default configuration).
The default privacy settings allow any remote entity to contact an MSN user, so the attacker is not required to be in the victim's buddy list. The attack can be mitigated by setting the privacy settings for MSN accounts to "Allow only the users below" (by default, the list of people on the buddy list).
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 a MSNSLP packet.
This affects at least two widely used products: Pidgin <= 2.5.8 [1] and Adium <= 1.3.5.
According to their website [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.
. Telepathy-Haze - a connection manager for the Telepathy IM framework.
These programs may also be vulnerable.
If the victim has its privacy settings set to "everyone can contact me", the victim is not required to be in the attacker's contact list.
Otherwise that is the only requirement for exploitation and no other victim interaction is required.
By sending a specially crafted packet, an attacker can write an arbitrary address with controlled data, resulting in arbitrary code execution.
A similar vulnerability was already reported in CVE-2008-2927 and
CVE-2009-1376. CVE-2008-2927 added some bounds checking in 'msn_slplink_process_msg()', specifically:
/-----------
if (G_MAXSIZE - len < offset || (offset='' + len='') > slpmsg->size) {
.. discard packet ..
} else {
.. vulnerable memcpy ..
}
- -----------/
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 64 bits integer was casted to an unsigned 32 bits integer in the following
line:
/-----------
declaration of offset;
...
offset = msg->msnslp_header.offset;
- -----------/
The declaration of offset was changed from 'gsize' to 'guint64' in 2.5.8. This approach is clearly not enough, we found that by providing 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 was incomplete.
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()' invocation in 'msn_slplink_process_msg()'. We need to construct a MSNSLP message with an offset different from zero (as this value will be the destination of the vulnerable 'memcpy()').
As the offset will be different from zero, the first problem arises when a call to 'msn_slplink_message_find()' returns NULL:
/-----------
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;
}
- -----------/
So, 'slpmsg' must be different from NULL. And this is exactly why this is a two-message attack. We need to send a first MSNSLP message, with an offset equal to zero, that constructs a slpmsg object, so Libpurple will store it. The second MSNSLP message will have an offset value different from zero, 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:
/-----------
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);
}
- -----------/
For example, if we construct our first MSNSLP message with a size of '0x01ffffff', and the second one (which is being processed and whose offset is assigned to the offset variable) has an offset of an arbitrary value lower than '0x01ffffff - len', then the conditions for an arbitrary write are met.
Finally, we reach 'memcpy()' with an offset of any value lower than '0x01ffffff - len' and the buffer pointing to 0. This means that we can write the contents of data in an arbitrary location lower than '0x01ffffff - len', which allows arbitrary code execution in almost any platform.
CVE Information:
CVE-2009-2694
2009-07-28 Notification of Pidgin team
2009-08-13 Pidgin team confirms Core that fixes will be ready by August 18th
2009-08-18 Advisory is published
|
|
|
|
|
