Talos Vulnerability Report


Pidgin libpurple Mxit Emoticon Name Length Integer Overflow Vulnerability

Jan 26, 2014


An exploitable remote code execution vulnerability exists in Pidgin''s implementation of the Mxit protocol in the libpurple library. An attacker who can control the contents of an Emoticon downloaded through the Mxit protocol can cause an allocation to return NULL which can later be used to write into the lowest page of memory. An attack requires the ability to spoof messages from the mxit.com domain to exploit this vulnerability.

Tested Versions

Pidgin 2.10.7

Product URLs



When downloading an emoticon via the mxit protocol, it is possible to cause a buffer overflow, by providing an invalid utf8 length. This occurs in the function asn_getUtf8() at line 216 of pidgin-2.10.7\libpurple\protocols\mxit\markup.c:

204     static int asn_getUtf8( const gchar* data, gchar type, char** utf8 )
        205         {
        206             int     len;
        208             /* validate the field type [1 byte] */
        209             if ( data[0] != type ) {
        210                 /* this is not a utf-8 string! */
        211                 purple_debug_error( MXIT_PLUGIN_ID, "Invalid UTF-8 encoded string in ASN data (got 0x%02X, expected 0x%02X)\n", data[0], type );
        212                 return -1;
        213             }

Here len will be read in as a 1 byte value from data[]. However, because len is a signed int, a length of 0xFF will be interpreted as a len of -1.

215             len = data[1];                      /* length field [1 bytes] */

The malloc at the next line will then result in an integer overflow at line 217.

216             *utf8 = g_malloc( len + 1 );
        217             memcpy( *utf8, &data[2], len );     /* data field */
        218             (*utf8)[len] = ''\0'';
        220             return ( len + 2 );
        221         }

Unlike libc malloc, gmalloc returns NULL when it is called with a size of zero. As a result of that behavior, this ends up being a a write to the NULL page rather than the typical heap overflow. Writes to the zero page are exploitable if an attacker can cause enough allocations and exhaust enough of the memory address range to make the system map the low page.


Discovered by Sourcefire VRT