Msn Icon DOS on 2.6.5
Elliott Sales de Andrade
qulogic at pidgin.im
Thu Feb 18 01:24:59 EST 2010
I can confirm this crash. I have attached a patch that fixes this issue.
I also checked other uses of msn_message_get_bin_data and they appear to be
fine.
On Wed, Feb 17, 2010 at 8:34 AM, Pierre Noguès <pierre at meta-security.com>wrote:
> Okey, I confirm tokens is NULL.
>
> g_strsplit will return NULL if you provide a NULL string in arg.
>
> In my case :
> body = msn_message_get_bin_data(msg, &body_len) return NULL
> body_str = g_strndup(body, body_len) return NULL too
>
> finally:
> tokens = g_strsplit(body_str, "\t", 10) return NULL because body_str is
> NULL
>
> Look at my verbose source code :
>
> [CODE]
> body = msn_message_get_bin_data(msg, &body_len);
> purple_debug_info("mydebug", "body: %p body_len:%d\n", body, body_len);
>
> body_str = g_strndup(body, body_len);
> purple_debug_info("mydebug", "body_str: %p\n", body_str);
>
>
> tokens = g_strsplit(body_str, "\t", 10);
> purple_debug_info("mydebug", "tokens: %p\n", tokens);
> [/CODE]
>
> It will output :
> (14:21:55) mydebug: msn_emoticon_msg
> (14:21:55) mydebug: body: (nil) body_len:0
> (14:21:55) mydebug: body_str: (nil)
> (14:21:55) GLib: g_strsplit: assertion `string != NULL' failed
> (14:21:55) mydebug: tokens: (nil)
>
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0x7fde4c78c7d0 (LWP 32093)]
> msn_emoticon_msg (cmdproc=<value optimized out>, msg=0x16cde00) at
> slp.c:927
> 927 if (tokens[tok] == NULL || tokens[tok + 1] == NULL)
> {
> (gdb) dns[32138]: nobody needs me... =(
> bt
> #0 msn_emoticon_msg (cmdproc=<value optimized out>, msg=0x16cde00) at
> slp.c:927
> #1 0x00007fde396741a2 in msn_cmdproc_process_msg (cmdproc=0x16c05b0,
> msg=0x16cde00) at cmdproc.c:312
> #2 0x00007fde396927fe in msg_cmd_post (cmdproc=0x16c05b0, cmd=0x16cf000,
> payload=0x16af89c "MIME-Version: 1.0\r\nContent-Type:
> text/x-mms-emoticon\r\n\r\n",
> len=56) at switchboard.c:790
> #3 0x00007fde3968bb8c in msn_servconn_process_data (servconn=0x16c3090) at
> servconn.c:487
> #4 0x00007fde3968bd27 in read_cb (data=0x16c3090, source=<value optimized
> out>, cond=<value optimized out>) at servconn.c:443
> #5 0x000000000046d54e in pidgin_io_invoke (source=<value optimized out>,
> condition=<value optimized out>, data=<value optimized out>) at
> gtkeventloop.c:78
> #6 0x00007fde4815a20a in g_main_context_dispatch () from
> /usr/lib/libglib-2.0.so.0
> #7 0x00007fde4815d8e0 in ?? () from /usr/lib/libglib-2.0.so.0
> #8 0x00007fde4815ddad in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
> #9 0x00007fde4a302bc7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
> #10 0x000000000048527f in main (argc=1, argv=0x7fffa71fdfd8) at
> gtkmain.c:978
>
> Look at the exploit, download java jml library
> http://sourceforge.net/apps/trac/java-jml version 1.03b (not the last).
>
>
>
> Sadrul Habib Chowdhury a écrit :
>
>> * 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
>>>
>>
> --
> Pierre Noguès - Meta Security
> Consultant en sécurité
>
> http://meta-security.com
> 40 rue Albéric de Calonne - 80 000 Amiens
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/cgi-bin/mailman/private/security/attachments/20100218/dc02c3de/attachment.htm>
-------------- next part --------------
#
# old_revision [e9d34ab5e47f22b35fd2d69d61a2c943cc0653db]
#
# patch "libpurple/protocols/msn/slp.c"
# from [3791d1f2ebc50ec51989809ba3548a65f9cacc84]
# to [c3a93aa383cd7efd916831614a22261ca525c31b]
#
============================================================
--- libpurple/protocols/msn/slp.c 3791d1f2ebc50ec51989809ba3548a65f9cacc84
+++ libpurple/protocols/msn/slp.c c3a93aa383cd7efd916831614a22261ca525c31b
@@ -929,6 +929,8 @@ msn_emoticon_msg(MsnCmdProc *cmdproc, Ms
conv = swboard->conv;
body = msn_message_get_bin_data(msg, &body_len);
+ if (!body || !body_len)
+ return;
body_str = g_strndup(body, body_len);
/* MSN Messenger 7 may send more than one MSNObject in a single message...
More information about the security
mailing list