Fedora Account System
Red Hat Associate
Red Hat Customer
It was reported that Wireshark's DEC DNA Routing Protocol dissector could crash. It may be possible to make Wireshark crash by injecting a malformed packet onto the wire or by convincing someone to read a malformed packet trace file. This is reported to affect Wireshark versions 1.12.0 to 1.12.2, and 1.10.0 to 1.10.11. It is fixed in versions 1.12.3 and 1.10.12. https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=10724 External References: https://www.wireshark.org/security/wnpa-sec-2015-03.html
Created wireshark tracking bugs for this issue: Affects: fedora-all [bug 1180183]
upstream fix ============ https://code.wireshark.org/review/gitweb?p=wireshark.git;a=patch;h=1bc3b8adb2ef850a0b90542bfac5f4b90f051e92
Analysis ======== In the code of DEC DNA Routing Protocol dissector in function set_dnet_address(packet_info *pinfo, address *paddr_src, address *paddr_tgt) { if (paddr_tgt->type != AT_STRINGZ && paddr_src->type == AT_ETHER) { char *addr = dnet_ntoa((const guint8 *)paddr_src->data); if (addr != NULL) SET_ADDRESS(paddr_tgt, AT_STRINGZ, 1, addr); } } when it executes SET_ADDRESS(paddr_tgt, AT_STRINGZ, 1, addr); the packet-scope memory might have been freed already which would lead to crash.
Correct me if I am wrong, I see the same code from comment 4 in the current RHEL-7 version wireshark-1.10.3-18.el7. But please, if fixing this, avoid introducing the CVE-2015-3182 into the code by applying a patch that uses wmem_strdup() without including appropriate wmem headers. Do it as Peter Hatina correctly did in the RHEL-6 version (wireshark branch 1.8.x), the old-school without wmem: - SET_ADDRESS(paddr_tgt, AT_STRINGZ, 1, addr); + SET_ADDRESS(paddr_tgt, AT_STRINGZ, 1, + ep_strdup(addr)); Or, with correct #include pragmas.
This issue has been addressed in the following products: Red Hat Enterprise Linux 6 Via RHSA-2015:1460 https://rhn.redhat.com/errata/RHSA-2015-1460.html
Unfortunately, I found segfault on rhel-7. # rpm -q wireshark wireshark-1.10.14-5.el7.x86_64 # tshark -nr fuzz-2014-11-22-10244.pcap Running as user "root" and group "root". This could be dangerous. 1 0.000000 10.63.64.186 -> 10.63.255.255 NBNS 96 Name query[Packet size limited during capture] 2 0.130333 10.63.64.186 -> 10.63.255.255 NBDS 223 Direct_group datagram[Packet size limited during capture] 3 0.130388 00:c0:4f:a4:a0:8a -> ff:ff:ff:ff:ff:ff ARP 64 Who has 10.63.1.20? Tell 10.63.64.186 4 0.239936 10.63.64.186 -> 10.174.255.255 NBNS 96 Name query[Packet size limited during capture] 5 0.240011 10.63.64.186 -> 10.63.255.255 NBNS 96 Name query[Packet size limited during capture] 6 0.286517 00:10:5a:21:47:ba -> ff:ff:ff:ff:ff:ff ARP 64 Who has 0a3f0113? Tell 0a3f403a [ETHERNET FRAME CHECK SEQUENCE INCORRECT] 7 0.343037 aa:00:04:00:30:05 -> ab:00:04:01:41:01 0x6007 132 DEC LAVC/SCA 8 0.474815 aa:00:04:00:fe:05 -> ab:00:04:01:fe:10 0x6007 132 DEC LAVC/SCA 9 0.479859 10.63.64.186 -> 10.63.255.255 NBNS 96 Name query[Packet size limited during capture] Segmentation fault All wireshark-1.10.14-*.el7 are affected, wireshark-1.10.3-20.el7 and less are not affected. If I run it with valgrind, no segfault appears.
This crash is actually related to rhbz#1219409. Fixed in wireshark-1.10.14-6.el7. (In reply to Jaroslav Aster from comment #13) > Unfortunately, I found segfault on rhel-7. > > # rpm -q wireshark > wireshark-1.10.14-5.el7.x86_64 > > # tshark -nr fuzz-2014-11-22-10244.pcap > Running as user "root" and group "root". This could be dangerous. > 1 0.000000 10.63.64.186 -> 10.63.255.255 NBNS 96 Name query[Packet size > limited during capture] > 2 0.130333 10.63.64.186 -> 10.63.255.255 NBDS 223 Direct_group > datagram[Packet size limited during capture] > 3 0.130388 00:c0:4f:a4:a0:8a -> ff:ff:ff:ff:ff:ff ARP 64 Who has > 10.63.1.20? Tell 10.63.64.186 > 4 0.239936 10.63.64.186 -> 10.174.255.255 NBNS 96 Name query[Packet size > limited during capture] > 5 0.240011 10.63.64.186 -> 10.63.255.255 NBNS 96 Name query[Packet size > limited during capture] > 6 0.286517 00:10:5a:21:47:ba -> ff:ff:ff:ff:ff:ff ARP 64 Who has > 0a3f0113? Tell 0a3f403a [ETHERNET FRAME CHECK SEQUENCE INCORRECT] > 7 0.343037 aa:00:04:00:30:05 -> ab:00:04:01:41:01 0x6007 132 DEC LAVC/SCA > 8 0.474815 aa:00:04:00:fe:05 -> ab:00:04:01:fe:10 0x6007 132 DEC LAVC/SCA > 9 0.479859 10.63.64.186 -> 10.63.255.255 NBNS 96 Name query[Packet size > limited during capture] > Segmentation fault > > All wireshark-1.10.14-*.el7 are affected, wireshark-1.10.3-20.el7 and less > are not affected. > > If I run it with valgrind, no segfault appears.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2015:2393 https://rhn.redhat.com/errata/RHSA-2015-2393.html
Statement: This issue affects the verison of wireshark as shipped with Red Hat Enterprsie Linux 5. Red Hat Enterprise Linux 5 is now in Production 3 Phase of the support and maintenance life cycle. This has been rated as having Moderate security impact and is not currently planned to be addressed in future updates.