Talos Vulnerability Report

Description

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

http://www.pidgin.im/

Details

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;
 207 
 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';
 219 
 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.