A buffer overflow flaw was found in the way that Wireshark 1.4.0 through 1.4.9 and 1.6.0 through 1.6.2 handled reading ERF files. This could cause wireshark to crash by reading a malformed packet trace file. This is corrected in wireshark 1.6.3.
References:
https://bugs.wireshark.org/bugzilla/showbug.cgi?id=6479 http://anonsvn.wireshark.org/viewvc?view=revision&revision=39508
External References:
http://www.wireshark.org/security/wnpa-sec-2011-19.html
An uninitialized variable in the CSN.1 dissector in Wireshark 1.6.0 through 1.6.2 could cause Wireshark to crash by reading a malformed packet trace file or if someone were to inject a malformed packet onto the the wire. This is corrected in wireshark 1.6.3.
References:
https://bugs.wireshark.org/bugzilla/showbug.cgi?id=6351 http://anonsvn.wireshark.org/viewvc?view=revision&revision=39140
External References:
http://www.wireshark.org/security/wnpa-sec-2011-17.html
A flaw in the Infiniband dissector could cause Wireshark 1.4.0 through 1.4.9 and 1.6.0 through 1.6.3 to crash by dereferencing a NULL pointer by reading a malformed packet trace file or if someone were to inject a malformed packet onto the wire. This is corrected in wireshark 1.6.3
References:
https://bugs.wireshark.org/bugzilla/showbug.cgi?id=6476 http://anonsvn.wireshark.org/viewvc?view=revision&revision=39500
External References:
http://www.wireshark.org/security/wnpa-sec-2011-18.html
A buffer exception handling vulnerability was found in wireshark. 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 affects versions 1.6.0 to 1.6.1 and has been fixed in version 1.6.2
Reference: http://www.wireshark.org/security/wnpa-sec-2011-14.html
This issue affects the versions of wireshark shipped with Fedora-14, Fedora-15 and the upcoming Fedora-16 and has been fixed via the following security advisories:
https://admin.fedoraproject.org/updates/FEDORA-2011-12423 https://admin.fedoraproject.org/updates/FEDORA-2011-12403 https://admin.fedoraproject.org/updates/FEDORA-2011-12399
An uninitialized variable flaw was found in the CSN.1 dissector of wireshark. 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 affects versions 1.6.0 to 1.6.1 and has been fixed in version 1.6.2
Reference: http://www.wireshark.org/security/wnpa-sec-2011-16.html
This issue affects the versions of wireshark shipped with Fedora-14, Fedora-15 and the upcoming Fedora-16 and has been fixed via the following security advisories:
https://admin.fedoraproject.org/updates/FEDORA-2011-12423 https://admin.fedoraproject.org/updates/FEDORA-2011-12403 https://admin.fedoraproject.org/updates/FEDORA-2011-12399
A large loop in the OpenSafety dissector could cause a 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 affects versions 1.6.0 to 1.6.1 and has been fixed in version 1.6.2
Reference: http://www.wireshark.org/security/wnpa-sec-2011-12.html
This issue affects the versions of wireshark shipped with Fedora-14, Fedora-15 and the upcoming Fedora-16 and has been fixed via the following security advisories:
https://admin.fedoraproject.org/updates/FEDORA-2011-12423 https://admin.fedoraproject.org/updates/FEDORA-2011-12403 https://admin.fedoraproject.org/updates/FEDORA-2011-12399
The prototreeadditem function in Wireshark 1.6.0 through 1.6.1 and 1.4.0 through 1.4.8, when the IKEv1 protocol dissector is used, allows user-assisted remote attackers to cause a denial of service (infinite loop) via vectors involving a malformed IKE packet and many items in a tree.
It was found that wireshark could run arbitrary Lua scripts.
Reference: http://www.wireshark.org/security/wnpa-sec-2011-15.html
This issue affects the versions of wireshark shipped with Fedora-14, Fedora-15 and the upcoming Fedora-16 and has been fixed via the following security advisories:
https://admin.fedoraproject.org/updates/FEDORA-2011-12423 https://admin.fedoraproject.org/updates/FEDORA-2011-12403 https://admin.fedoraproject.org/updates/FEDORA-2011-12399
The Lucent/Ascend file parser in Wireshark 1.2.x before 1.2.18, 1.4.x through 1.4.7, and 1.6.0 allows remote attackers to cause a denial of service (infinite loop) via malformed packets.
An infinite loop was found in the way ANSI A Interface (IS-634/IOS) dissector of the Wireshark network traffic analyzer processed certain ANSI A MAP capture files. If Wireshark read a malformed packet off a network or opened a malicious packet capture file, it could lead to denial of service (Wireshark hang).
Upstream bug: [1] https://bugs.wireshark.org/bugzilla/showbug.cgi?id=6044
Public PoC: [2] http://www.wireshark.org/download/automated/captures/fuzz-2011-06-20-22762.pcap
Relevant upstream patch: [3] http://anonsvn.wireshark.org/viewvc?view=revision&revision=37930
References: [4] http://www.wireshark.org/security/ [5] http://www.wireshark.org/security/wnpa-sec-2011-11.html [6] http://www.wireshark.org/security/wnpa-sec-2011-10.html
The dissectwtpcommon function in epan/dissectors/packet-wtp.c in the WTP dissector in Wireshark 1.6.x before 1.6.12 and 1.8.x before 1.8.4 uses an incorrect data type for a certain length field, which allows remote attackers to cause a denial of service (integer overflow and infinite loop) via a crafted value in a packet.
Integer overflow in the dissectiscsipdu function in epan/dissectors/packet-iscsi.c in the iSCSI dissector in Wireshark 1.6.x before 1.6.12 and 1.8.x before 1.8.4 allows remote attackers to cause a denial of service (infinite loop) via a malformed packet.
Integer overflow in the dissecticmpv6 function in epan/dissectors/packet-icmpv6.c in the ICMPv6 dissector in Wireshark 1.6.x before 1.6.12 and 1.8.x before 1.8.4 allows remote attackers to cause a denial of service (infinite loop) via a crafted Number of Sources value.
epan/dissectors/packet-usb.c in the USB dissector in Wireshark 1.6.x before 1.6.12 and 1.8.x before 1.8.4 relies on a length field to calculate an offset value, which allows remote attackers to cause a denial of service (infinite loop) via a zero value for this field.
The dissectrtcpapp function in epan/dissectors/packet-rtcp.c in the RTCP dissector in Wireshark 1.6.x before 1.6.12 and 1.8.x before 1.8.4 allows remote attackers to cause a denial of service (infinite loop) via a crafted packet.
The dissectisakmp function in epan/dissectors/packet-isakmp.c in the ISAKMP dissector in Wireshark 1.6.x before 1.6.12 and 1.8.x before 1.8.4 uses an incorrect data structure to determine IKEv2 decryption parameters, which allows remote attackers to cause a denial of service (application crash) via a malformed packet.
The PPP dissector in Wireshark 1.4.x before 1.4.14, 1.6.x before 1.6.9, and 1.8.x before 1.8.1 allows remote attackers to cause a denial of service (invalid pointer dereference and application crash) via a crafted packet, as demonstrated by a usbmon dump.
epan/dissectors/packet-nfs.c in the NFS dissector in Wireshark 1.4.x before 1.4.14, 1.6.x before 1.6.9, and 1.8.x before 1.8.1 allows remote attackers to cause a denial of service (loop and CPU consumption) via a crafted packet.
Multiple integer underflows in Wireshark 1.4.x before 1.4.13 and 1.6.x before 1.6.8 allow remote attackers to cause a denial of service (loop) via vectors related to the R3 dissector, a different vulnerability than CVE-2012-2392.
Multiple integer overflows in Wireshark 1.4.x before 1.4.13 and 1.6.x before 1.6.8 allow remote attackers to cause a denial of service (infinite loop) via vectors related to the (1) BACapp and (2) Bluetooth HCI dissectors, a different vulnerability than CVE-2012-2392.
Description of problem: When opening certain capture files, wireshark hangs forever in an endless loop.
Version-Release number of selected component (if applicable): wireshark-1.6.8-1.fc16.x8664
I compiled wireshark 1.8.2 from source and did not see this problem any more.
How reproducible: always
Steps to Reproduce: 1. open capture file with wireshark Actual results: hangs after reading ~25% of the data
Expected results: opens file successfully
Additional info:
#0 tvbgetntohs (tvb=<optimized out>, offset=<optimized out>) at tvbuff.c:1163 #1 0x00007fe66e6884ca in dissectdrda (tvb=0x7fe673ab7a40, pinfo=0x7fff420367f0, tree=0x0) at packet-drda.c:695 #2 0x00007fe66e688a9f in dissectdrdaheur (tree=0x0, pinfo=0x7fff420367f0, tvb=0x7fe673ab7a40) at packet-drda.c:819 #3 dissectdrdaheur (tvb=0x7fe673ab7a40, pinfo=0x7fff420367f0, tree=0x0) at packet-drda.c:803 #4 0x00007fe66e472844 in dissectortryheuristic (subdissectors=<optimized out>, tvb=0x7fe673ab7a40, pinfo=0x7fff420367f0, tree=0x0) at packet.c:1657 #5 0x00007fe66ea32ba0 in decodetcpports (tvb=<optimized out>, offset=<optimized out>, pinfo=0x7fff420367f0, tree=0x0, srcport=<optimized out>, dstport=<optimized out>, tcpd=0x7fe656e2b080) at packet-tcp.c:3413 #6 0x00007fe66ea330a8 in processtcppayload (tvb=0x7fe673ab7980, offset=32, pinfo=0x7fff420367f0, tree=0x0, tcptree=0x0, srcport= 2049, dstport=676, seq=0, nxtseq=0, istcpsegment=0, tcpd=0x7fe656e2b080) at packet-tcp.c:3458 #7 0x00007fe66ea33651 in desegmenttcp (tcpd=0x7fe656e2b080, tcptree=0x0, tree=0x0, dport=676, sport=2049, nxtseq=128380061, seq= 128380023, offset=32, pinfo=0x7fff420367f0, tvb=0x7fe673ab7980) at packet-tcp.c:1708 #8 dissecttcppayload (tvb=0x7fe673ab7980, pinfo=0x7fff420367f0, offset=<optimized out>, seq=<optimized out>, nxtseq=128380061, sport= 2049, dport=676, tree=0x0, tcptree=0x0, tcpd=0x7fe656e2b080) at packet-tcp.c:3525 #9 0x00007fe66ea34ac0 in dissecttcp (tvb=<optimized out>, pinfo=0x7fff420367f0, tree=0x0) at packet-tcp.c:4233 #10 0x00007fe66e4706e0 in calldissectorthroughhandle (handle=0x7fe672eaafa0, tvb=0x7fe673ab7980, pinfo=0x7fff420367f0, tree=0x0) at packet.c:420 #11 0x00007fe66e470db5 in calldissectorwork (handle=0x7fe672eaafa0, tvb=0x7fe673ab7980, pinfoarg=0x7fff420367f0, tree=0x0, addprotoname=1) at packet.c:511 #12 0x00007fe66e4718e6 in dissectortryuintnew (subdissectors=<optimized out>, uintval=6, tvb=0x7fe673ab7980, pinfo=0x7fff420367f0, tree=0x0, addprotoname=1) at packet.c:923 #13 0x00007fe66e7a931d in dissectip (tvb=0x7fe673ab7b60, pinfo=<optimized out>, parenttree=0x0) at packet-ip.c:1841 #14 0x00007fe66e4706e0 in calldissectorthroughhandle (handle=0x7fe672aaff90, tvb=0x7fe673ab7b60, pinfo=0x7fff420367f0, tree=0x0) at packet.c:420 #15 0x00007fe66e470db5 in calldissectorwork (handle=0x7fe672aaff90, tvb=0x7fe673ab7b60, pinfoarg=0x7fff420367f0, tree=0x0, addprotoname=1) at packet.c:511 #16 0x00007fe66e4718e6 in dissectortryuintnew (subdissectors=<optimized out>, uintval=2048, tvb=0x7fe673ab7b60, pinfo= 0x7fff420367f0, tree=0x0, addprotoname=1) at packet.c:923 #17 0x00007fe66e6b21d7 in ethertype (etype=2048, tvb=0x7fe673ab7aa0, offsetafteretype=14, pinfo=0x7fff420367f0, tree=0x0, fhtree=0x0, etypeid=18803, trailerid=18805, fcslen=-1) at packet-ethertype.c:262 #18 0x00007fe66e6b0e59 in dissectethcommon (tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, parenttree=0x0, fcslen=-1) at packet-eth.c:348 #19 0x00007fe66e4706e0 in calldissectorthroughhandle (handle=0x7fe6729356b0, tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, tree=0x0) at packet.c:420 #20 0x00007fe66e470db5 in calldissectorwork (handle=0x7fe6729356b0, tvb=0x7fe673ab7aa0, pinfoarg=0x7fff420367f0, tree=0x0, addprotoname=1) at packet.c:511 #21 0x00007fe66e4718e6 in dissectortryuintnew (subdissectors=<optimized out>, uintval=1, tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, tree=0x0, addprotoname=1) at packet.c:923 ---Type <return> to continue, or q <return> to quit--- #22 0x00007fe66e6e5ea9 in dissectframe (tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, parenttree=0x0) at packet-frame.c:345 #23 0x00007fe66e4706e0 in calldissectorthroughhandle (handle=0x7fe67297b180, tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, tree=0x0) at packet.c:420 #24 0x00007fe66e470db5 in calldissectorwork (handle=0x7fe67297b180, tvb=0x7fe673ab7aa0, pinfoarg=0x7fff420367f0, tree=0x0, addprotoname=1) at packet.c:511 #25 0x00007fe66e473171 in calldissector (handle=<optimized out>, tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, tree=0x0) at packet.c:1864 #26 0x00007fe66e473594 in dissectpacket (edt=0x7fff420367e0, pseudoheader=0x0, pd=0x7fe673a2e890 "", fd=0x7fe673f6c6d0, cinfo=0x0) at packet.c:351 #27 0x00007fe6711311fd in addpackettopacketlist (fdata=0x7fe673f6c6d0, cf=0x7fe6714e6e60, dfcode=0x0, filteringtaplisteners=0, tapflags=<optimized out>, pseudoheader=0x7fe6739f6c40, buf=0x7fe673a2e890 "", addtopacketlist=1, refilter=1) at file.c:1111 #28 0x00007fe6711314aa in readpacket (cf=0x7fe6714e6e60, dfcode=0x0, filteringtaplisteners=0, tapflags=4, offset=<optimized out>) at file.c:1200 #29 0x00007fe671131d48 in cfread (cf=0x7fe6714e6e60, fromsave=0) at file.c:609 #30 0x00007fe67111db5f in main (argc=0, argv=0x7fff42037428) at main.c:2877
The code hangs in this loop:
dissectdrda () { [...] 693 while ((guint) (offset + 10) <= tvblength(tvb)) 694 { 695 iCommand = tvbgetntohs(tvb, offset + 8); 696 iLength = tvbgetntohs(tvb, offset + 0); 697 / iCommandEnd is the length of the packet up to the end of the current command / 698 iCommandEnd += iLength; [...] 707 if (tree) 708 { [...] 776 } 777 else 778 { 779 / No tree, advance directly to next command / (gdb) 780 offset += iLength; 781 } 782 }
tvbgetntohs() in line 696 returns 0, thus the "offset" variable never advances.
epan/dissectors/packet-diameter.c in the DIAMETER dissector in Wireshark 1.4.x before 1.4.13 and 1.6.x before 1.6.8 does not properly construct certain array data structures, which allows remote attackers to cause a denial of service (application crash) via a crafted packet that triggers incorrect memory allocation.
Wireshark 1.4.x before 1.4.13 and 1.6.x before 1.6.8 on the SPARC and Itanium platforms does not properly perform data alignment for a certain structure member, which allows remote attackers to cause a denial of service (application crash) via a (1) ICMP or (2) ICMPv6 Echo Request packet.
Wireshark 1.4.x before 1.4.13 and 1.6.x before 1.6.8 allows remote attackers to cause a denial of service (infinite loop) via vectors related to the (1) ANSI MAP, (2) ASF, (3) IEEE 802.11, (4) IEEE 802.3, and (5) LTP dissectors.
The lanalyzerread function in wiretap/lanalyzer.c in Wireshark 1.4.x before 1.4.11 and 1.6.x before 1.6.5 allows remote attackers to cause a denial of service (application crash) via a Novell capture file containing a record that is too small.
wiretap/iptrace.c in Wireshark 1.4.x before 1.4.11 and 1.6.x before 1.6.5 allows remote attackers to cause a denial of service (application crash) via a long packet in an AIX iptrace file.
Wireshark 1.4.x before 1.4.11 and 1.6.x before 1.6.5 allows remote attackers to cause a denial of service (application crash) via a long packet in a (1) Accellent 5Views (aka .5vw) file, (2) I4B trace file, or (3) NETMON 2 capture file.
The fragmentaddseqcommon function in epan/reassemble.c in the ASN.1 BER dissector in Wireshark before r48943 has an incorrect pointer dereference during a comparison, which allows remote attackers to cause a denial of service (application crash) via a malformed packet.
The dissectberchoice function in epan/dissectors/packet-ber.c in the ASN.1 BER dissector in Wireshark 1.6.x before 1.6.15 and 1.8.x before 1.8.7 does not properly initialize a certain variable, which allows remote attackers to cause a denial of service (application crash) via a malformed packet.