Monday, January 27, 2014

VRT-2013-1002 (CVE-2013-6489): Buffer overflow in MXit emoticon parsing

Sourcefire Vulnerability Report VRT-2013-1002 (CVE-2013-6489): Buffer overflow in MXit emoticon parsing

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

Coverage 

SID 28088

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 integer, a length of 0xFF will be interpreted as a len of -1.

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

The memory allocation at the next line will then result in an integer overflow, resulting in a buffer 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's memory allocator, 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.

No comments:

Post a Comment