Wireshark-bugs: [Wireshark-bugs] [Bug 4914] New: The packet-nbns.c dissector picks random data a
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4914
Summary: The packet-nbns.c dissector picks random data as the
NBSS PDU length in certain situations
Product: Wireshark
Version: 1.4.0
Platform: All
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: fschorr@xxxxxxxxxxx
Created an attachment (id=4834)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=4834)
capture showing the problem
Build Information:
Version 1.4.0rc1 (SVN Rev 33190 from /trunk-1.4)
Copyright 1998-2010 Gerald Combs <gerald@xxxxxxxxxxxxx> and contributors.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled with GTK+ 2.16.6, (32-bit) with GLib 2.22.4, with WinPcap (version
unknown), with libz 1.2.3, without POSIX capabilities, without libpcre, with
SMI
0.4.8, with c-ares 1.7.1, with Lua 5.1, without Python, with GnuTLS 2.8.5, with
Gcrypt 1.4.5, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built
Jun
9 2010), with AirPcap.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.1
(packet.dll version 4.1.0.1753), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.8.5, Gcrypt 1.4.5, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 30729
--
This problem seems to occur when trying to dissect NBSS PDU after there is
network traffic missing from the capture for the TCP stream being dissected.
I'm attaching capture nbss-bug-one_direction.cap as an example. In this
capture the missing network traffic occurs just before frame 59.
The packet_nbns.c dissector starts with frame 59 to try to find a legitimate
NBSS header. To do this currently, the dissector looks at the first byte in
the current TVB to see if it's a valid message type, values 0, 5, 6, 7, 8, 9,
and 15. If the first byte in the TVB happens to contain one of these values,
part of or all of the next 3 bytes is treated as the PDU length field and
tested for different values. The case that is causing this problem is when the
opcode is a 0 or a Session Message. For this case, the length field is only
checked to see if it's a 0 and if it is, the frame is discarded as starting
with a valid NBSS header.
The dissector goes through frames 59 to frame 76 and rejects each of these
frames. However, in frame 77 it turns out that the first byte (offset 0x0042)
is a 0 and the next three bytes are greater then 0 bytes (0xdb47ac or
14,370,732 bytes). The outcome is the the dissector then incorrectly treats
the next 14,370,732 bytes in the TCP stream as being all in a NBSS PDU.
To add another sanity check as to the validity of the NBSS header, I propose
also checking the length field to make sure the length is not greater then
65536 bytes as this is the largest PDU we see in a CFIS/SMB environment. I
have also considered looking at 5 to 8 bytes in to the TVB to see if it
contains "SMB" as an additional test (or perhaps in lieu of the above test).
If this last item seem to be the best solution please let me know as I already
have the code written to to this additional test.
I'm attaching both an example capture and my proposed change/patch.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
