libpurple IRC TOPIC message Denial of Service

Cristofaro Mune pulsoid at icysilence.org
Thu Sep 3 11:04:07 EDT 2009


Hi,

a vulnerability present in libpurple released with the current version
of Pidgin (2.6.1).
It may allow a malicious IRC server to remotely crash libpurple and the
overlying application.

Receiving the following message from an IRC server:

:hostile TOPIC\r\n #room :topic\r\n

causes a segmentation fault because of a NULL ptr dereference, occurring
in the for loop at line 467 inside irc_mirc2txt.
This happens because both irc_msg_topic in msgs.c and irc_mirc2txt in
parse.c do not  perform checks for NULL input parameters.

Briefly, the the incoming message is processed by read_input in irc.c,
where it is changed into

:hostile TOPIC\0\n #room :topic\r\n

before being parsed by irc_parse_msg.

This function identifies irc_msg_topic as the callback function for
handling the topic message, and it attempts to build the args array with
the needed information (channel and topic description).
In doing this it creates a zero filled array (g_new0 at line 691 in
parse.c), that fails being properly populated because of the null byte
right after TOPIC.
This zero filled array is passed to irc_msg_topic, that passes it
straight away to irc_mirc2txt, without performing any check on it.

irc_mirc2txt is then called with NULL (stored in args[1]) as argument
(line 449 in msgs.c).
It will perform a g_strdup on the input (line 466 in parse.c), without
checking for NULL.
g_strdup returns NULL into the result variable and, again, this value is
not checked before being directly used in the following for loop (line
467), leading to the NULL ptr dereference and the segfault.

This behaviour has been succesfully reproduced on Pidgin (Windows XP and
Ubuntu 9.04) and finch.
The following message is also able to trigger the vulnerability:

:hostile TOPIC #room\r\n :topic\r\n

A backtrace of the crash from a debug enabled finch follows, along with
a quickly coded proof of concept, attached for testing purposes.
If needed, a slightly more detailed analysis is available on
http://www.icysilence.org

Hope this helps.

Best Regards,
Cristofaro Mune

---------------------

//Attack string:
//":hostile TOPIC\r\n #testroom :newtopic\r\n"

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb78416c0 (LWP 10897)]
irc_mirc2txt (string=0x0) at parse.c:467
467             for (i = 0, j = 0; result[i]; i++) {
(gdb) bt            ▒│
#0  irc_mirc2txt (string=0x0) at parse.c:467
#1  0xb7515515 in irc_msg_topic (irc=0x91a86a0, name=0xb75183fd "topic",
    from=0x91a9f60 "hostile", args=0x91a7640) at msgs.c:449
#2  0xb7517062 in irc_parse_msg (irc=0x91a86a0,
    input=0x91a8f90 ":hostile TOPIC") at parse.c:723
#3  0xb7511153 in read_input (irc=0x91a86a0, len=<value optimized out>)
    at irc.c:625    ▒│
#4  0x0806a483 in purple_gnt_io_invoke (source=0x914d160,
    condition=<value optimized out>, data=0x91a7620) at finch.c:169
#5  0xb7c12dad in ?? () from /usr/lib/libglib-2.0.so.0
#6  0xb7bdbb88 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#7  0xb7bdf0eb in ?? () from /usr/lib/libglib-2.0.so.0
#8  0xb7bdf5ba in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#9  0xb8022fd5 in gnt_main () at gntmain.c:516
#10 0x0806a05e in main (argc=1, argv=Cannot access memory at address 0x4
) at finch.c:439─────┘
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libpurple_IRC_TOPIC_DOS_POC.py
Type: text/x-python
Size: 1234 bytes
Desc: not available
URL: <http://pidgin.im/pipermail/devel/attachments/20090903/622f611c/attachment-0002.py>


More information about the Devel mailing list