CVE-2012-3548: Medium severity wireshark vulnerability

Published Aug 21, 2012
·
Updated

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

14 affected components
Wireshark Wireshark=1.8.0
Wireshark Wireshark=1.8.1
Wireshark Wireshark=1.8.2
Wireshark Wireshark=1.6.0
Wireshark Wireshark=1.6.1
Wireshark Wireshark=1.6.2
Wireshark Wireshark=1.6.3
Wireshark Wireshark=1.6.4
Wireshark Wireshark=1.6.5
Wireshark Wireshark=1.6.6
Wireshark Wireshark=1.6.7
Wireshark Wireshark=1.6.8
Wireshark Wireshark=1.6.9
Wireshark Wireshark=1.6.10

Event History

Aug 21, 2012
Data Sourced
09:06 AM
DescriptionSeverityAffected Software
Aug 30, 2012
CVE Published
via MITRE·10:00 PM
Data Sourced
via MITRE·10:00 PM
Description

Frequently Asked Questions

1

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.

2

How do I fix CVE-2012-3548?

To fix CVE-2012-3548, upgrade to Wireshark version 1.8.2 or later.

3

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.

4

What symptoms indicate CVE-2012-3548?

Symptoms of CVE-2012-3548 include Wireshark hanging indefinitely when opening specific capture files.

5

Is CVE-2012-3548 reproducible?

Yes, CVE-2012-3548 is reproducible every time when opening certain problematic capture files.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203