Bug 849926 - (CVE-2012-3548) CVE-2012-3548 wireshark (X >= 1.6.8): DoS (excessive CPU use and infinite loop) in DRDA dissector
CVE-2012-3548 wireshark (X >= 1.6.8): DoS (excessive CPU use and infinite loo...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
Unspecified Unspecified
low Severity low
: ---
: ---
Assigned To: Red Hat Product Security
impact=low,public=20120821,reported=2...
: Security
: CVE-2012-5239 (view as bug list)
Depends On: 852796
Blocks: 852798
  Show dependency treegraph
 
Reported: 2012-08-21 05:06 EDT by Martin Wilck
Modified: 2016-03-04 07:33 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-08-30 01:31:05 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sample capture file (2.95 MB, application/x-gzip)
2012-08-21 05:08 EDT, Martin Wilck
no flags Details

  None (edit)
Description Martin Wilck 2012-08-21 05:06:58 EDT
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.
Comment 1 Martin Wilck 2012-08-21 05:08:06 EDT
Created attachment 605891 [details]
sample capture file

I see the problem with this capture file.
Comment 2 Martin Wilck 2012-08-21 05:08:59 EDT
I can provide a core dump (70MB compressed) if desired.
Comment 3 Jan Safranek 2012-08-27 10:32:07 EDT
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.
Comment 4 Jan Safranek 2012-08-27 11:09:14 EDT
Reported upstream: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7666
Comment 5 Martin Wilck 2012-08-27 11:10:44 EDT
(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.
Comment 6 Jan Lieskovsky 2012-08-29 11:15:19 EDT
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
Comment 7 Jan Lieskovsky 2012-08-29 11:26:40 EDT
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
Comment 8 Jan Lieskovsky 2012-08-29 11:41:02 EDT
CVE request:
http://www.openwall.com/lists/oss-security/2012/08/29/2
Comment 9 Jan Lieskovsky 2012-08-29 11:43:25 EDT
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.
Comment 10 Jan Lieskovsky 2012-08-29 11:44:28 EDT
Created wireshark tracking bugs for this issue

Affects: fedora-all [bug 852796]
Comment 11 Kurt Seifried 2012-08-29 14:26:01 EDT
Added CVE as per http://www.openwall.com/lists/oss-security/2012/08/29/4
Comment 12 Huzaifa S. Sidhpurwala 2012-08-30 01:29:21 EDT
Statement:

Not Vulnerable. This issue does not affect the version of wireshark as shipped with Red Hat Enterprise Linux 5 and 6.
Comment 13 Huzaifa S. Sidhpurwala 2012-08-30 01:31:05 EDT
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.
Comment 14 Jan Lieskovsky 2012-09-05 09:46:44 EDT
Upstream patch:
http://anonsvn.wireshark.org/viewvc?view=revision&revision=44749
Comment 15 Huzaifa S. Sidhpurwala 2012-10-03 04:21:22 EDT
*** Bug 862508 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.