Bug 849926 (CVE-2012-3548)
| Summary: | CVE-2012-3548 wireshark (X >= 1.6.8): DoS (excessive CPU use and infinite loop) in DRDA dissector | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Other] Security Response | Reporter: | Martin Wilck <martin.wilck> | ||||
| Component: | vulnerability | Assignee: | Red Hat Product Security <security-response-team> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | |||||
| Severity: | low | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | unspecified | CC: | huzaifas, jlieskov, jrusnack, jsafrane, mapcode.mind, rvokal | ||||
| Target Milestone: | --- | Keywords: | Security | ||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2012-08-30 05:31:05 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | 852796 | ||||||
| Bug Blocks: | 852798 | ||||||
| Attachments: |
|
||||||
Created attachment 605891 [details]
sample capture file
I see the problem with this capture file.
I can provide a core dump (70MB compressed) if desired. Thanks for the report, I can reproduce the bug with your .cap file, no need for the core file. However, vanilla wireshark 1.8.2 also loops indefinitely. I hope the capture file does not contain any sensitive data as I am going to send it upstream. Reported upstream: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7666 (In reply to comment #3) > Thanks for the report, I can reproduce the bug with your .cap file, no need > for the core file. However, vanilla wireshark 1.8.2 also loops indefinitely. Hmm, you're right - strange, I'd bet I was able to open it with 1.8.2 last week. The problem seems to be that wireshark wrongly assumes this to be "drda" traffic (because of the client port 676??). It hangs while trying to reassemble this traffic. when started with tshark -r test.cap.gz tshark also hangs at frame #28881. but tshark can be told how to decode the traffic. tshark -d tcp.port==2049,rpc -r test.cap.gz works fine. Unfortunately I have found no option to tell the GUI tool how to decode certain ports. > I hope the capture file does not contain any sensitive data as I am going to > send it upstream. I captured only frame headers, so it should be fine. However next time please wait for an answer before doing this. Thank you for your report, Martin. I am going to steal this bug to be Security Response product based one (since this is a security flaw / DoS), and does not affect Fedora-16's based wireshark version only. Thank you && Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team A denial of service flaw was found in the way Distributed Relational Database Architecture (DRDA) dissector of Wireshark, a network traffic analyzer, performed processing of certain DRDA packet capture files. A remote attacker could create a specially-crafted capture file that, when opened could lead to wireshark executable to consume excessive amount of CPU time and hang with an infinite loop. Issue found by: Martin Wilck This issue did NOT affect the versions of the wireshark package, as shipped with Red Hat Enterprise Linux 5 and 6. -- This issue affects the versions of the wireshark package, as shipped with Fedora release of 16 and 17. Please schedule an update once there is final upstream patch available. Created wireshark tracking bugs for this issue Affects: fedora-all [bug 852796] Added CVE as per http://www.openwall.com/lists/oss-security/2012/08/29/4 Statement: Not Vulnerable. This issue does not affect the version of wireshark as shipped with Red Hat Enterprise Linux 5 and 6. I am going to close this bug, as Red Hat Enterprise Linux is not affected. Please use bug #852796 for committing the patch related to this flaw in fedora. Upstream patch: http://anonsvn.wireshark.org/viewvc?view=revision&revision=44749 *** Bug 862508 has been marked as a duplicate of this bug. *** |
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.x86_64 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 tvb_get_ntohs (tvb=<optimized out>, offset=<optimized out>) at tvbuff.c:1163 #1 0x00007fe66e6884ca in dissect_drda (tvb=0x7fe673ab7a40, pinfo=0x7fff420367f0, tree=0x0) at packet-drda.c:695 #2 0x00007fe66e688a9f in dissect_drda_heur (tree=0x0, pinfo=0x7fff420367f0, tvb=0x7fe673ab7a40) at packet-drda.c:819 #3 dissect_drda_heur (tvb=0x7fe673ab7a40, pinfo=0x7fff420367f0, tree=0x0) at packet-drda.c:803 #4 0x00007fe66e472844 in dissector_try_heuristic (sub_dissectors=<optimized out>, tvb=0x7fe673ab7a40, pinfo=0x7fff420367f0, tree=0x0) at packet.c:1657 #5 0x00007fe66ea32ba0 in decode_tcp_ports (tvb=<optimized out>, offset=<optimized out>, pinfo=0x7fff420367f0, tree=0x0, src_port=<optimized out>, dst_port=<optimized out>, tcpd=0x7fe656e2b080) at packet-tcp.c:3413 #6 0x00007fe66ea330a8 in process_tcp_payload (tvb=0x7fe673ab7980, offset=32, pinfo=0x7fff420367f0, tree=0x0, tcp_tree=0x0, src_port= 2049, dst_port=676, seq=0, nxtseq=0, is_tcp_segment=0, tcpd=0x7fe656e2b080) at packet-tcp.c:3458 #7 0x00007fe66ea33651 in desegment_tcp (tcpd=0x7fe656e2b080, tcp_tree=0x0, tree=0x0, dport=676, sport=2049, nxtseq=128380061, seq= 128380023, offset=32, pinfo=0x7fff420367f0, tvb=0x7fe673ab7980) at packet-tcp.c:1708 #8 dissect_tcp_payload (tvb=0x7fe673ab7980, pinfo=0x7fff420367f0, offset=<optimized out>, seq=<optimized out>, nxtseq=128380061, sport= 2049, dport=676, tree=0x0, tcp_tree=0x0, tcpd=0x7fe656e2b080) at packet-tcp.c:3525 #9 0x00007fe66ea34ac0 in dissect_tcp (tvb=<optimized out>, pinfo=0x7fff420367f0, tree=0x0) at packet-tcp.c:4233 #10 0x00007fe66e4706e0 in call_dissector_through_handle (handle=0x7fe672eaafa0, tvb=0x7fe673ab7980, pinfo=0x7fff420367f0, tree=0x0) at packet.c:420 #11 0x00007fe66e470db5 in call_dissector_work (handle=0x7fe672eaafa0, tvb=0x7fe673ab7980, pinfo_arg=0x7fff420367f0, tree=0x0, add_proto_name=1) at packet.c:511 #12 0x00007fe66e4718e6 in dissector_try_uint_new (sub_dissectors=<optimized out>, uint_val=6, tvb=0x7fe673ab7980, pinfo=0x7fff420367f0, tree=0x0, add_proto_name=1) at packet.c:923 #13 0x00007fe66e7a931d in dissect_ip (tvb=0x7fe673ab7b60, pinfo=<optimized out>, parent_tree=0x0) at packet-ip.c:1841 #14 0x00007fe66e4706e0 in call_dissector_through_handle (handle=0x7fe672aaff90, tvb=0x7fe673ab7b60, pinfo=0x7fff420367f0, tree=0x0) at packet.c:420 #15 0x00007fe66e470db5 in call_dissector_work (handle=0x7fe672aaff90, tvb=0x7fe673ab7b60, pinfo_arg=0x7fff420367f0, tree=0x0, add_proto_name=1) at packet.c:511 #16 0x00007fe66e4718e6 in dissector_try_uint_new (sub_dissectors=<optimized out>, uint_val=2048, tvb=0x7fe673ab7b60, pinfo= 0x7fff420367f0, tree=0x0, add_proto_name=1) at packet.c:923 #17 0x00007fe66e6b21d7 in ethertype (etype=2048, tvb=0x7fe673ab7aa0, offset_after_etype=14, pinfo=0x7fff420367f0, tree=0x0, fh_tree=0x0, etype_id=18803, trailer_id=18805, fcs_len=-1) at packet-ethertype.c:262 #18 0x00007fe66e6b0e59 in dissect_eth_common (tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, parent_tree=0x0, fcs_len=-1) at packet-eth.c:348 #19 0x00007fe66e4706e0 in call_dissector_through_handle (handle=0x7fe6729356b0, tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, tree=0x0) at packet.c:420 #20 0x00007fe66e470db5 in call_dissector_work (handle=0x7fe6729356b0, tvb=0x7fe673ab7aa0, pinfo_arg=0x7fff420367f0, tree=0x0, add_proto_name=1) at packet.c:511 #21 0x00007fe66e4718e6 in dissector_try_uint_new (sub_dissectors=<optimized out>, uint_val=1, tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, tree=0x0, add_proto_name=1) at packet.c:923 ---Type <return> to continue, or q <return> to quit--- #22 0x00007fe66e6e5ea9 in dissect_frame (tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, parent_tree=0x0) at packet-frame.c:345 #23 0x00007fe66e4706e0 in call_dissector_through_handle (handle=0x7fe67297b180, tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, tree=0x0) at packet.c:420 #24 0x00007fe66e470db5 in call_dissector_work (handle=0x7fe67297b180, tvb=0x7fe673ab7aa0, pinfo_arg=0x7fff420367f0, tree=0x0, add_proto_name=1) at packet.c:511 #25 0x00007fe66e473171 in call_dissector (handle=<optimized out>, tvb=0x7fe673ab7aa0, pinfo=0x7fff420367f0, tree=0x0) at packet.c:1864 #26 0x00007fe66e473594 in dissect_packet (edt=0x7fff420367e0, pseudo_header=0x0, pd=0x7fe673a2e890 "", fd=0x7fe673f6c6d0, cinfo=0x0) at packet.c:351 #27 0x00007fe6711311fd in add_packet_to_packet_list (fdata=0x7fe673f6c6d0, cf=0x7fe6714e6e60, dfcode=0x0, filtering_tap_listeners=0, tap_flags=<optimized out>, pseudo_header=0x7fe6739f6c40, buf=0x7fe673a2e890 "", add_to_packet_list=1, refilter=1) at file.c:1111 #28 0x00007fe6711314aa in read_packet (cf=0x7fe6714e6e60, dfcode=0x0, filtering_tap_listeners=0, tap_flags=4, offset=<optimized out>) at file.c:1200 #29 0x00007fe671131d48 in cf_read (cf=0x7fe6714e6e60, from_save=0) at file.c:609 #30 0x00007fe67111db5f in main (argc=0, argv=0x7fff42037428) at main.c:2877 The code hangs in this loop: dissect_drda () { [...] 693 while ((guint) (offset + 10) <= tvb_length(tvb)) 694 { 695 iCommand = tvb_get_ntohs(tvb, offset + 8); 696 iLength = tvb_get_ntohs(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 } tvb_get_ntohs() in line 696 returns 0, thus the "offset" variable never advances.