CVE-2012-3548: Medium severity wireshark vulnerability
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.
Other sources
The dissectdrda function in epan/dissectors/packet-drda.c in Wireshark 1.6.x through 1.6.10 and 1.8.x through 1.8.2 allows remote attackers to cause a denial of service (infinite loop and CPU consumption) via a small value for a certain length field in a capture file.
— MITRE
Affected Software
Remediation
Patch Available
Event History
Frequently Asked Questions
What is the severity of CVE-2012-3548?
CVE-2012-3548 is considered to have a moderate severity rating due to the potential for application hang.
How do I fix CVE-2012-3548?
To fix CVE-2012-3548, upgrade to Wireshark version 1.8.2 or later.
Which versions are affected by CVE-2012-3548?
CVE-2012-3548 affects Wireshark versions prior to 1.8.2, including 1.6.0 through 1.6.10 and 1.8.0 and 1.8.1.
What symptoms indicate CVE-2012-3548?
Symptoms of CVE-2012-3548 include Wireshark hanging indefinitely when opening specific capture files.
Is CVE-2012-3548 reproducible?
Yes, CVE-2012-3548 is reproducible every time when opening certain problematic capture files.