Pidgin MXIT g_snprintf Multiple Buffer Overflow Vulnerabilities(CVE-2016-2368)

### DESCRIPTION Multiple memory corruption vulnerabilities exist in the handling of the MXIT protocol in Pidgin. Specially crafted MXIT data sent via the server could result in multiple buffer overflows, potentially resulting in code execution or memory disclosure. ### CVSSv3 SCORE 7.5 CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H ### TESTED VERSIONS Pidgin 2.10.11 ### PRODUCT URLs https://www.pidgin.im/ ### DETAILS The MXIT plugin for Pidgin uses the function gsnprintf in about 27 places where it receives the return value of the function. When gsnprintf returns, it will return the number of bytes that would have been written had the buffer been large enough, not the amount of bytes that have actually been written. This is described at https://developer.gnome.org/glib/stable/glib-String-Utility-Functions.html#g-snprintf. The MXIT plugin uses the return value of gsnprintf as an index or an offset into the string that is being manipulated in multiple locations without making sure that the return value is within bounds. This could potentially lead to a buffer overflow. While it is recommended that all return values of gsnprintf are checked, the following 12 calls spread over 7 functions appear to be the most problematic as they will copy data that might come from an untrusted location into a string. The following functions are all defined in the file mxit/protocol.c Function: mxit_send_invite() Lines: 1015-1024 ``` 1015 datalen = g_snprintf( data, sizeof( data ), "ms=%s%c%s%c%s%c%i%c%s%c%i", groupname, CP_FLD_TERM, username, CP_FLD_TERM, alias, CP_FLD_TERM, MXIT_TYPE_MXIT, CP_FLD_TERM, ( message ? message : "" ), CP_FLD_TERM, ( mxitid ? 0 : 1 )); /* queue packet for transmission */ 1024 mxit_queue_packet( session, data, datalen, CP_CMD_INVITE ); ``` The data passed into g_snprintf comes from both the server and the user and the return value will be used to specify the bounds of the data to be sent in the function mxit_queue_packet, potentially resulting in an out-of-bounds read of data which will be sent to the server, which might cause an information leak. Function: mxit_queue_packet() Lines: 467-479 ``` 467 hlen = g_snprintf( header, sizeof( header ), "id=%s%c", purple_account_get_username( session->acc ), CP_REC_TERM ); /* client mxitid */ if ( session->http ) { /* http connection only */ 471 hlen += g_snprintf( header + hlen, sizeof( header ) - hlen, "s="); if ( session->http_sesid > 0 ) { 473 hlen += g_snprintf( header + hlen, sizeof( header ) - hlen, "%u%c", session->http_sesid, CP_FLD_TERM ); /* http session id */ } session->http_seqno++; 476 hlen += g_snprintf( header + hlen, sizeof( header ) - hlen, "%u%c", session->http_seqno, CP_REC_TERM ); /* http request sequence id */ } 479 hlen += g_snprintf( header + hlen, sizeof( header ) - hlen, "cm=%i%c", cmd, CP_REC_TERM ); /* packet command */ ``` A long user account returned at line 467 will potentially cause buffer overflows at lines 471, 473, 476 or 479. Function: mxitsendmessage() Lines: 808-817 ``` 808 datalen = g_snprintf( data, sizeof( data ), "ms=%s%c%s%c%i%c%i", /* "ms"=jid\1msg\1type\1flags */ to, CP_FLD_TERM, markuped_msg, CP_FLD_TERM, msgtype, CP_FLD_TERM, CP_MSG_MARKUP | CP_MSG_EMOTICON); /* free the resources */ g_free( markuped_msg ); /* queue packet for transmission */ 817 mxit_queue_packet( session, data, datalen, CP_CMD_TX_MSG ); ``` Data passed to mxitsendmessage comes from the server and the user in the variables to and msg respectively. The variable msg might also contain data coming from the server if itÕs the result of a clicked link. This will subsequently result in an out-of-bounds read of data sent back to the server in mxit_queue_packet, which might cause an information leak. Function: mxit_write_http_post() Lines: 355-369 ``` 355 reqlen = g_snprintf( request, 256, "POST %s?%s HTTP/1.1\r\n" "User-Agent: " MXIT_HTTP_USERAGENT "\r\n" "Content-Type: application/octet-stream\r\n" "Host: %s\r\n" "Content-Length: %d\r\n" "\r\n", session->http_server, purple_url_encode( packet->header ), host_name, packet->datalen - MXIT_MS_OFFSET ); /* copy over the packet body data (could be binary) */ 369 memcpy( request + reqlen, packet->data + MXIT_MS_OFFSET, packet->datalen - MXIT_MS_OFFSET ); ``` The size of the packet->header combined with the URL and the other data being printed could result in a value larger than 256, resulting in a buffer overflow at line 369. The packet->header will be set in mxitqueuepacket, which is discussed earlier in this advisory. Function: mxitsendsplashclick() Lines 1136-1142 ``` 1136 datalen = g_snprintf( data, sizeof( data ), "ms=%s", /* "ms"=splashId */ splashid ); /* queue packet for transmission */ 1142 mxit_queue_packet( session, data, datalen, CP_CMD_SPLASHCLICK ); ``` Splash id is data that comes from the server, which is used in the gsnprintf() call, potentially resulting in an out-of-bounds read in mxitqueue_packet. Since this data is sent back to the server, this could result in an information leak. Function: mxitsendsuggest_search() Lines: 937-946 ``` 937 datalen = g_snprintf( data, sizeof( data ), "ms=%i%c%s%c%i%c%i%c%i",CP_SUGGEST_SEARCH, CP_FLD_TERM, text, CP_FLD_TERM, max, CP_FLD_TERM, 0, CP_FLD_TERM, nr_attrib ); /* add attributes */ for ( i = 0; i < nr_attrib; i++ ) 942 datalen += g_snprintf( data + datalen, sizeof( data ) - datalen, "%c%s", CP_FLD_TERM, attribute[i] ); /* queue packet for transmission */ 946 mxit_queue_packet( session, data, datalen, CP_CMD_SUGGESTCONTACTS ); ``` The value text will come from the user, who could be tricked into entering a potential long string. This could then result in a buffer overflow at line 942 and an out-of-bounds read leading to an information leak at line 946. Function: mxit_send_msgevent Lines 1162-1168 ``` 1162 datalen = g_snprintf( data, sizeof( data ), "ms=%s%c%s%c%i", /* "ms"=contactAddress \1 id \1 event */ to, CP_FLD_TERM, id, CP_FLD_TERM, event); /* queue packet for transmission */ 1168 mxit_queue_packet( session, data, datalen, CP_CMD_MSGEVENT ); ``` The issue is the same as before, to and id come from the server and are used in line 1162, which could result in an information leak at line 1168. ### TIMELINE * 2016-04-13 - Vendor Notification * 2016-06-21 - Public Disclosure