Hash: SHA1

             AUSCERT External Security Bulletin Redistribution

     Libpurple msn_slplink_process_msg() Arbitrary Write Vulnerability
                              20 August 2009


        AusCERT Security Bulletin Summary

Product:           libpurple
Publisher:         Core Security Technologies
Operating System:  Windows
                   UNIX variants (UNIX, Linux, OSX)
Impact/Access:     Execute Arbitrary Code/Commands -- Remote/Unauthenticated
Resolution:        Patch/Upgrade
CVE Names:         CVE-2009-2694  

Original Bulletin: 

Revision History:  August 20 2009: Updated with signed Core advisory.
                   August 19 2009: Initial Release

- --------------------------BEGIN INCLUDED TEXT--------------------

Hash: SHA1

      Core Security Technologies - CoreLabs Advisory

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

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

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


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

- - -----------/

 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)
          "Oversized slpmsg - msgsize=%lld offset=%" G_GSIZE_FORMAT "
len=%" G_GSIZE_FORMAT "\n",
          slpmsg->size, offset, len);
        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

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
[6] 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:

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

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
Version: GnuPG v1.4.8 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


- --------------------------END INCLUDED TEXT--------------------

You have received this e-mail bulletin as a result of your organisation's
registration with AusCERT. The mailing list you are subscribed to is
maintained within your organisation, so if you do not wish to continue
receiving these bulletins you should contact your local IT manager. If
you do not know who that is, please send an email to auscert@auscert.org.au
and we will forward your request to the appropriate person.

NOTE: Third Party Rights
This security bulletin is provided as a service to AusCERT's members.  As
AusCERT did not write the document quoted above, AusCERT has had no control
over its content. The decision to follow or act on information or advice
contained in this security bulletin is the responsibility of each user or
organisation, and should be considered in accordance with your organisation's
site policies and procedures. AusCERT takes no responsibility for consequences
which may arise from following or acting on information or advice contained in
this security bulletin.

NOTE: This is only the original release of the security bulletin.  It may
not be updated when updates to the original are made.  If downloading at
a later date, it is recommended that the bulletin is retrieved directly
from the author's website to ensure that the information is still current.

Contact information for the authors of the original document is included
in the Security Bulletin above.  If you have any questions or need further
information, please contact them directly.

Previous advisories and external security bulletins can be retrieved from:


If you believe that your computer system has been compromised or attacked in 
any way, we encourage you to let us know by completing the secure National IT 
Incident Reporting Form at:


Australian Computer Emergency Response Team
The University of Queensland
Qld 4072

Internet Email: auscert@auscert.org.au
Facsimile:      (07) 3365 7031
Telephone:      (07) 3365 4417 (International: +61 7 3365 4417)
                AusCERT personnel answer during Queensland business hours
                which are GMT+10:00 (AEST).
                On call after hours for member emergencies only.
Comment: https://www.auscert.org.au/1967