Msn Icon DOS on 2.6.5

[Sadrul Habib Chowdhury]

* Pierre Noguès had this to say on [17 Feb 2010, 14:05:43 +0100]:
> OK I said shit i'll send you exploit to reproduce the bug and a deeper backtrack.

That'd be great. Thanks.

PS: Please reply to the list.

Sadrul

> Pierre Noguès a écrit :
>> Yes maybe tokens isn't null but *tokens or tokens[1] should be NULL or  
>> not initialized.
>>
 
>> http://library.gnome.org/devel/glib/unstable/glib-String-Utility-Functions.html#g-strsplit 
>> 
>>
>> Returns :
>>     a newly-allocated NULL-terminated array of strings. Use 
>> g_strfreev() to free it.
>>
>> Regarding the help if we don't have '\t', tokens[0] or tokens[1] should 
>> be NULL, try something like that:
>> printf("tokens = %p\n", *tokens);
>> printf("tokens = %p\n", tokens[1]);
>>
>> Sadrul Habib Chowdhury a écrit :
>>> * 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
>>>
>>
>
> -- 
> Pierre Noguès - Meta Security
> Consultant en sécurité
>
> http://meta-security.com
> 40 rue Albéric de Calonne - 80 000 Amiens