Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 6473] New: ASN.1 PER bitfield dissector problems

Date: Thu, 20 Oct 2011 09:05:51 -0700 (PDT)
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.