report wireshark bug - Stack exhaustion in xml GUI display

[Liuyinsheng <liuyinsheng.liu () huawei com>]

Dear all,

I have report a vulnerability about wireshark (with version 2.0.2) on Wireshark Bug Database with BugID 12268 about a 
month ago. But I still haven't received a reply. So I report my my findings in this way.
This vulnerability will cause wireshark crash with stack exhaustion, when opening crafted pcap file.

The details as below, same as the record in Wireshark Bug 
Database(https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=12268)


The product version and trigger environment:

Compiled (64-bit) with Qt 5.3.2, with WinPcap (4_1_3), with libz 1.2.8, with
GLib 2.42.0, with SMI 0.4.8, with c-ares 1.9.1, with Lua 5.2, with GnuTLS
3.2.15, with Gcrypt 1.6.2, with MIT Kerberos, with GeoIP, with QtMultimedia,
with AirPcap.

Running on 64-bit Windows 7 Service Pack 1, build 7601, with locale C, with
WinPcap version 4.1.2 (packet.dll version 4.1.0.2001), based on libpcap version
1.0 branch 1_0_rel0b (20091008), with GnuTLS 3.2.15, with Gcrypt 1.6.2, without
AirPcap.

Intel(R) Xeon(R) CPU E5-2690 v2 @ 3.00GHz (with SSE4.2), with 6135MB of physical memory.

Built using Microsoft Visual C++ 12.0 build 31101


Some simple analysis:

There exist a stack exhaustion vulnerability in libwireshark.dll, which is caused by deep recursive call in 
proto_tree_traverse_post_order function.

gboolean proto_tree_traverse_post_order(proto_tree *tree, proto_tree_traverse_func func, gpointer data)
{
    proto_node *pnode = tree;
    proto_node *child;
    proto_node *current;
    child = pnode->first_child;

   while (child != NULL) {

        /*
        * The routine we call might modify the child, e.g. by
        * freeing it, so we get the child's successor before
        * calling that routine.
        */

        current = child;
        child   = current->next;
        if (proto_tree_traverse_post_order((proto_tree *)current, func, data))
            return TRUE;
    }

    if (func(pnode, data))
        return TRUE;

    return FALSE;
}

When open the crafted poc file, and click the final http 200 packet the vulnerability will be trigered. The application 
will crash.

I have tested this problem in 2.0.1 and 2.0.2.
But the legency version seems not be affected.


You can find debug information, poc file, and dump files, in attachments.

Best regards!

Attachment: wireshark.zip
Description: wireshark.zip

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe