Message-ID: <4A8B229D.7010602@coresecurity.com>
Date: Tue, 18 Aug 2009 18:52:29 -0300
From: CORE Security Technologies Advisories <advisories@...esecurity.com>
To: Bugtraq <bugtraq@...urityfocus.com>,
	full-disclosure@...ts.grok.org.uk
Subject: CORE-2009-0727: Libpurple msn_slplink_process_msg() Arbitrary Write
 Vulnerability

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

      Core Security Technologies - CoreLabs Advisory
           http://www.coresecurity.com/corelabs/

Libpurple msn_slplink_process_msg() Arbitrary Write Vulnerability



1. *Advisory Information*

Title: Libpurple msn_slplink_process_msg() Arbitrary Write Vulnerability
Advisory ID: CORE-2009-0727
Advisory URL: http://www.coresecurity.com/content/libpurple-arbitrary-write
Date published: 2009-08-18
Date of last update: 2009-08-18
Vendors contacted: Pidgin team
Release mode: Coordinated release


2. *Vulnerability Information*

Class: Memory corruption
Remotely Exploitable: Yes
Locally Exploitable: No
Bugtraq ID:
CVE Name: CVE-2009-2694


3. *Vulnerability Description*

Pidgin (formerly named Gaim) is a multi-platform instant messaging
client, based on a library named libpurple. Libpurple has support for
many commonly used instant messaging protocols, allowing the user to log
into various different services from one application.

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 [4] 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).


4. *Vulnerable packages*

   . 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.


5. *Non-vulnerable packages*

   . Libpurple >= 2.6.0 (Pidgin >= 2.6.0)


6. *Vendor Information, Solutions and Workarounds*

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).


7. *Credits*

This vulnerability was discovered and researched by Federico Muttis from
Core Security Technologies.


8. *Technical Description / Proof of Concept Code*


8.1. *Overview*

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 [4].

This affects at least two widely used products: Pidgin <= 2.5.8 [1] and
Adium <= 1.3.5 [2].

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.


8.2. *Previous patches*

A similar vulnerability was already reported in CVE-2008-2927 [5] and
CVE-2009-1376 [6]. 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.


8.3. *Exploitation of Libpurple 2.5.8*

The attack consists in sending two consecutive MSNSLP messages [4]. 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.


9. *Report Timeline*

. 2009-07-28:
Core Security Technologies notifies the Pidgin team of the vulnerability
and schedules a preliminary publication date to August 18th.

. 2009-07-28:
Pidgin team requests technical details (in plaintext or encrypted).

. 2009-07-30:
Core sends the advisory draft, encrypted, including technical details.

. 2009-07-30:
Pidgin team acknowledges reception of the draft.

. 2009-07-31:
Pidgin team notifies Core that they cannot reproduce the bug.

. 2009-07-31:
Core sends proof of concept code to the Pidgin team.

. 2009-08-10:
Core requests the Pidgin team an update on the bug status and fixes.

. 2009-08-13:
Pidgin team confirms Core that fixes will be ready by August 18th, and
sends information regarding affected versions and mitigations.

. 2009-08-13:
Core acknowledges the information sent by Pidgin team.

. 2009-08-18:
The advisory CORE-2009-0727 is published.



10. *References*

[1] Pidgin http://www.pidgin.im/
[2] Adium http://adium.im/
[3] Libpurple http://developer.pidgin.im/wiki/WhatIsLibpurple
[4] MSNSLP http://msnpiki.msnfanatic.com/index.php/MSNC:MSNSLP
[5] CVE-2008-2927
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2927
[6] CVE-2009-1376
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-1376


11. *About CoreLabs*

CoreLabs, the research center of Core Security Technologies, is charged
with anticipating the future needs and requirements for information
security technologies. We conduct our research in several important
areas of computer security including system vulnerabilities, cyber
attack planning and simulation, source code auditing, and cryptography.
Our results include problem formalization, identification of
vulnerabilities, novel solutions and prototypes for new technologies.
CoreLabs regularly publishes security advisories, technical papers,
project information and shared software tools for public use at:
http://www.coresecurity.com/corelabs.


12. *About Core Security Technologies*

Core Security Technologies develops strategic solutions that help
security-conscious organizations worldwide develop and maintain a
proactive process for securing their networks. The company's flagship
product, CORE IMPACT, is the most comprehensive product for performing
enterprise security assurance testing. CORE IMPACT evaluates network,
endpoint and end-user vulnerabilities and identifies what resources are
exposed. It enables organizations to determine if current security
investments are detecting and preventing attacks. Core Security
Technologies augments its leading technology solution with world-class
security consulting services, including penetration testing and software
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core
Security Technologies can be reached at 617-399-6980 or on the Web at
http://www.coresecurity.com.


13. *Disclaimer*

The contents of this advisory are copyright (c) 2009 Core Security
Technologies and (c) 2009 CoreLabs, and may be distributed freely
provided that no fee is charged for this distribution and proper credit
is given.


14. *PGP/GPG Keys*

This advisory has been signed with the GPG key of Core Security
Technologies advisories team, which is available for download at
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkqLIpwACgkQyNibggitWa2yqgCeJ3qxJluj3aNZzz3Y6XPULeHa
KG8AnRiJXqQ/XX2E0UKb1sQOeWGfJhIc
=GQCO
-----END PGP SIGNATURE-----

Powered by blists - more mailing lists