Msn Icon DOS on 2.6.5

Sadrul Habib Chowdhury sadrul at pidgin.im
Wed Feb 17 07:52:09 EST 2010


* Pierre Noguès had this to say on [17 Feb 2010, 13:23:24 +0100]:
> Hello,
>
> I discovered a low severity vulnerability which can lead to a remote dos 
> of pidgin. This vulnerability can't be exploited to lead to a remote code 
> execution. Tested on 2.6.5.
>
> The vulnerability is located in slp.c here :
>
>     msn_emoticon_msg(MsnCmdProc *cmdproc, MsnMessage *msg){
>
>         //...
>         tokens = g_strsplit(body_str, "\t", 10);
>         //tokens can be null !
>
>         //...
> 		if (tokens[tok] == NULL || tokens[tok + 1] == NULL) {
>                 //ref NULL pointer => CRASH
>
> When msg doesn't contain '\t' char in his body, g_strsplit return NULL, 

g_strsplit doesn't seem to return NULL in such cases, e.g. try the
following code:

	#include <glib.h>

	int main()
	{
		const char *string = "0123456789";
		char **tokens = g_strsplit(string, "\t", 10);
		printf("tokens = %p\n", tokens);
		g_strfreev(tokens);
		return 0;
	}

What version of glib are you using?

> this NULL pointer is referenced in READ ACCESS in the for loop. That's 
> why it crash.
>
> Backtrace:
>     #0  0x00007f54b6de3473 in msn_emoticon_msg () from /usr/lib/purple-2/libmsn.so
>     #1  0x00007f54b6dcbb32 in msn_cmdproc_process_msg () from /usr/lib/purple-2/libmsn.so
>     #2  0x00007f54b6de80e4 in ?? () from /usr/lib/purple-2/libmsn.so
>     #3  0x00007f54b6de1e7c in msn_servconn_process_data () from /usr/lib/purple-2/libmsn.so
>     #4  0x00007f54b6de2022 in ?? () from /usr/lib/purple-2/libmsn.so
>     #5  0x000000000046661e in ?? ()
>     #6  0x00007f54cae7820a in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
>     #7  0x00007f54cae7b8e0 in ?? () from /usr/lib/libglib-2.0.so.0
>     #8  0x00007f54cae7bdad in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
>     #9  0x00007f54cc02abc7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
>     #10 0x000000000047dc83 in main ()
>

Perhaps something else is causing the crash? A more verbose backtrace
could be useful.

> Solution:
> Check if tokens isn't null before entering in the loop.
>
> Reproduce the bug:
> Just send a mime message with content-type "text/x-mms-emoticon" and no icon. It will crash.

Do you have any test program/code/patch that can be used to recreate
the crash?

Cheers,
Sadrul



More information about the security mailing list