Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 281545 (CVE-2009-2694) - <net-im/pidgin-2.5.9 msn_slplink_process_msg() Memory overwrite (CVE-2009-2694)
Summary: <net-im/pidgin-2.5.9 msn_slplink_process_msg() Memory overwrite (CVE-2009-2694)
Status: RESOLVED FIXED
Alias: CVE-2009-2694
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
URL: http://pidgin.im/news/security/?id=34
Whiteboard: B1 [glsa]
Keywords:
: 281958 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-08-15 06:21 UTC by Robert Buchholz (RETIRED)
Modified: 2009-10-22 19:12 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
fix_for_msn_remote_crash.diff (pidgin-2.5.8-msn-remote-crash.patch,909 bytes, patch)
2009-08-15 06:25 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff
ebuild (pidgin-2.5.8-r1.ebuild,4.38 KB, text/plain)
2009-08-15 15:42 UTC, Olivier Crete (RETIRED)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Robert Buchholz (RETIRED) gentoo-dev 2009-08-15 06:21:54 UTC
** 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
Comment 1 Robert Buchholz (RETIRED) gentoo-dev 2009-08-15 06:25:15 UTC
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.
Comment 2 Robert Buchholz (RETIRED) gentoo-dev 2009-08-15 06:25:51 UTC
Created attachment 201303 [details, diff]
fix_for_msn_remote_crash.diff
Comment 3 Olivier Crete (RETIRED) gentoo-dev 2009-08-15 15:42:14 UTC
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.
Comment 4 Olivier Crete (RETIRED) gentoo-dev 2009-08-15 15:44:06 UTC
Btw, this should be B1, its a "remote active compromise", one can remotely execute arbritrary code.
Comment 5 Robert Buchholz (RETIRED) gentoo-dev 2009-08-15 20:03:41 UTC
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
Comment 6 Christian Faulhammer (RETIRED) gentoo-dev 2009-08-16 09:12:12 UTC
Good on x86.
Comment 7 Tobias Heinlein (RETIRED) gentoo-dev 2009-08-16 10:30:47 UTC
Looks fine on amd64.
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2009-08-16 15:33:15 UTC
HPPA is OK.
Comment 9 Robert Buchholz (RETIRED) gentoo-dev 2009-08-18 20:16:21 UTC
now public
Comment 10 Robert Buchholz (RETIRED) gentoo-dev 2009-08-18 20:16:40 UTC
*** Bug 281958 has been marked as a duplicate of this bug. ***
Comment 11 Robert Buchholz (RETIRED) gentoo-dev 2009-08-18 20:17:11 UTC
now public and/or bump to 2.5.9
Comment 12 Olivier Crete (RETIRED) gentoo-dev 2009-08-18 21:00:22 UTC
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.
Comment 13 Robert Buchholz (RETIRED) gentoo-dev 2009-08-18 21:10:01 UTC
Arches, please test and mark stable:
=net-im/pidgin-2.5.9
Target keywords : "alpha amd64 hppa ia64 ppc ppc64 sparc x86"
Comment 14 Christian Faulhammer (RETIRED) gentoo-dev 2009-08-18 22:31:29 UTC
x86 stable
Comment 15 Jeroen Roovers (RETIRED) gentoo-dev 2009-08-19 16:12:48 UTC
Stable for HPPA.
Comment 16 Alex Legler (RETIRED) archtester gentoo-dev Security 2009-08-21 19:49:51 UTC
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.

Comment 17 Alex Legler (RETIRED) archtester gentoo-dev Security 2009-08-21 22:59:30 UTC
amd64 stable
Comment 18 nixnut (RETIRED) gentoo-dev 2009-08-23 08:35:14 UTC
ppc stable
Comment 19 Raúl Porcel (RETIRED) gentoo-dev 2009-08-25 13:29:58 UTC
alpha/ia64/sparc stable
Comment 20 Brent Baude (RETIRED) gentoo-dev 2009-08-30 23:33:33 UTC
ppc64 done
Comment 21 Alex Legler (RETIRED) archtester gentoo-dev Security 2009-08-31 07:25:12 UTC
GLSA request filed.
Comment 22 Alex Legler (RETIRED) archtester gentoo-dev Security 2009-08-31 08:30:46 UTC
Olivier/net-im: Please remove vulnerable versions.
Comment 23 Olivier Crete (RETIRED) gentoo-dev 2009-08-31 15:48:13 UTC
version 2.5.8 cleaned up
Comment 24 Tobias Heinlein (RETIRED) gentoo-dev 2009-10-22 19:12:43 UTC
GLSA 200910-02, thanks everyone, sorry about the delay.