Wireshark-bugs: [Wireshark-bugs] [Bug 6473] New: ASN.1 PER bitfield dissector problems
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6473
Summary: ASN.1 PER bitfield dissector problems
Product: Wireshark
Version: 1.6.2
Platform: x86
OS/Version: Windows XP
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: Neil.Piercy@xxxxxxxxxxxx
Neil Piercy <Neil.Piercy@xxxxxxxxxxxx> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #7278| |review_for_checkin?
Flag| |
Created an attachment (id=7278)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7278)
Patch to fix padding and bit stitching problems in bitstrings
Build Information:
wireshark 1.6.2
Copyright 1998-2011 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 (32-bit) with GTK+ 2.22.1, with GLib 2.26.1, with WinPcap (version
unknown), with libz 1.2.5, 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.10.3,
with
Gcrypt 1.4.6, with MIT Kerberos, with GeoIP, with PortAudio V19-devel (built
Oct
11 2011), with AirPcap.
Running on Windows XP Service Pack 3, build 2600, with WinPcap version 4.1.2
(packet.dll version 4.1.0.2001), based on libpcap version 1.0 branch 1_0_rel0b
(20091008), GnuTLS 2.10.3, Gcrypt 1.4.6, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 30729
--
In the display of bit strings in packet-per.c there are 2 problems when bit
strings are not octet aligned and not whole octet values, as illustrated by the
following extracts (from a 3GPP RRC message - sorry the transport is private
protocol, so I cannot attach the source packet trace with any meaning):
Wrong values 1.6.2:
srnc-Identity: 0904 [bit length 12, 4 LSB pad bits, 0000 1001 0000 ....
decimal value 144]
s-RNTI: 5ec040 [bit length 20, 4 LSB pad bits, 1110 1100 0000 0000 0100 ....
decimal value 6209540]
Correct values after fix applied to 1.6.2:
srnc-Identity: 0900 [bit length 12, 4 LSB pad bits, 0000 1001 0000 ....
decimal value 144]
s-RNTI: 5ec050 [bit length 20, 4 LSB pad bits, 0101 1110 1100 0000 0101 ....
decimal value 388101]
The problems are:
a) The hex display immediately after the field name includes the wrong bits in
the final octet: this has been traced to a reuse of a value which should
contain the number of bits to include and ends up containing the number of bits
remaining _before the field is octet aligned_.
b) The binary display and decimal values are corrupt in the case where they are
"stitched" together from words and octets: the complete words are extracted
ready for LSB padding, but when the final octet/word is added (also so
extracted), the data already present is shifted by a whole number of octets
(not allowing for the padding), and the value is then used by the binary and
decimal display functions as if it were MSB padded. This results in both a
corrupt bit pattern and wrong padding of the bit pattern in the display.
Patch to fix attached. Sorry about the lack of test data which I can usefully
share.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
