Libpurple msn_slplink_process_msg() Arbitrary Write Vulnerability

Advisory ID Internal
CORE-2009-0727

1. Advisory Information

Title: Libpurple msn_slplink_process_msg() Arbitrary Write Vulnerability
Advisory ID: CORE-2009-0727
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 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.5.9 (Pidgin >= 2.5.9)

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.

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.

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 [4] and CVE-2009-1376 [5]. 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 guint64in 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. 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 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.
  • 2009-08-19: Core modifies advisory CORE-2009-0727 including version Libpurple 2.5.9 as patched and also including link to Pidgin advisory in Vendor section.

10. References

[1] Pidgin http://www.pidgin.im/
[2] Adium http://adium.im/
[3] Libpurple http://developer.pidgin.im/wiki/WhatIsLibpurple
[4] CVE-2008-2927 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2927
[4] 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, 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: www.coresecurity.com/core-labs.

12. About Core Security 

Core Security 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 augments its leading technology solution with world-class security consulting services, including penetration testing and software security auditing. 

13. Disclaimer

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