Talos Vulnerability Report


Pidgin MXIT g_snprintf Multiple Buffer Overflow Vulnerabilities

June 21, 2016
CVE Number



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.


7.5 CVSS:3.0/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H


Pidgin 2.10.11




The MXIT plugin for Pidgin uses the function g_snprintf in about 27 places where it receives the return value of the function. When g_snprintf 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 g_snprintf 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 g_snprintf 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 */
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: mxit_send_message() Lines: 808-817

808	datalen = g_snprintf( data, sizeof( data ),
	"ms=%s%c%s%c%i%c%i",		/* "ms"=jid\1msg\1type\1flags */

	/* 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 mxit_send_message 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"
					purple_url_encode( packet->header ),
					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 mxit_queue_packet, which is discussed earlier in this advisory.

Function: mxit_send_splashclick() Lines 1136-1142

1136	datalen = g_snprintf( data, sizeof( data ),
	"ms=%s",	/* "ms"=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 g_snprintf() call, potentially resulting in an out-of-bounds read in mxit_queue_packet. Since this data is sent back to the server, this could result in an information leak.

Function: mxit_send_suggest_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.


2016-04-13 - Vendor Notification
2016-06-21 - Public Disclosure


Discovered by Yves Younan of Cisco Talos.