Wireshark-bugs: [Wireshark-bugs] [Bug 4053] New: TCAP problem with indefinite length 'components
Date Index · Thread Index · Other Months · All Mailing Lists
Date Prev · Date Next · Thread Prev · Thread Next
From: bugzilla-daemon@xxxxxxxxxxxxx
Date: Fri, 25 Sep 2009 07:22:21 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=4053

           Summary: TCAP problem with indefinite length 'components' SEQ OF
           Product: Wireshark
           Version: SVN
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: Normal
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: dimeg@xxxxxxxxxxx



Gerasimos Dimitriadis <dimeg@xxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #3703|                            |review_for_checkin?
               Flag|                            |


Created an attachment (id=3703)
 --> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3703)
Patch for correct indefinite length on SEQ OF decoding

Build Information:
wireshark 1.3.1 (SVN Rev 30113 from /trunk)

Copyright 1998-2009 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.12.9, with GLib 2.16.3, with libpcap 0.9.8, with libz
1.2.3, without POSIX capabilities, with libpcre 7.6, without SMI, without
c-ares, without ADNS, without Lua, without Python, with GnuTLS 2.2.2, with
Gcrypt 1.4.0, without Kerberos, without GeoIP, without PortAudio, without
AirPcap, with new_packet_list.

Running on Linux 2.6.25.16-0.1-default, with libpcap version 0.9.8, GnuTLS
2.2.2, Gcrypt 1.4.0.

Built using gcc 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036].

--
Hi all,

I have encountered an issue with TCAP messages. Specifically, when the
'components' SEQ OF is coded with indefinite length, then the EOC is not
recognized, but rather it is considered to be just another item in the SEQ OF. 
The result of this is that 2 components are reported inside the SEQ OF, even
though the corresponding subtree normally shows only one.

If the internal BER encapsulation tokens are activated, then a NULL tag-zero
length element can be seen immediately after the valid component. Furthermore,
we see that after the wrongly decoded 'components' SEQ OF, a SEQ FIELD EOC has
been inserted. 

Regarding the first issue, there are some if(ind) checks that are removed in
the attached patch. From what I understood, this was an issue with SEQ also. 

Regarding the second issue, the dissect_ber_sequence should increase seq after
the checks on seq->flags & BER_FLAGS_NOOWNTAG are done.

I also attach a MAP message where this issue appears.

Regards,

Gerasimos


-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.