https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=3597
Summary: Implicit octet string that is constructed causes
PRES/FTAM dissect failure
Product: Wireshark
Version: 1.2.0
Platform: All
OS/Version: All
Status: NEW
Severity: Normal
Priority: Low
Component: Wireshark
AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
ReportedBy: fgruman@xxxxxxxxx
Created an attachment (id=3195)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=3195)
FTAM protocol capture
Build Information:
Version 1.2.0 (SVN Rev 28753)
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.16.2, with GLib 2.20.3, with WinPcap (version unknown),
with libz 1.2.3, without POSIX capabilities, with libpcre 7.0, with SMI 0.4.8,
with c-ares 1.6.0, with Lua 5.1, with GnuTLS 2.8.1, with Gcrypt 1.4.4, with MIT
Kerberos, with GeoIP, with PortAudio V19-devel (built Jun 15 2009), with
AirPcap.
Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.1
beta5
(packet.dll version 4.1.0.1452), based on libpcap version 1.0.0, GnuTLS 2.8.1,
Gcrypt 1.4.4, without AirPcap.
Built using Microsoft Visual C++ 9.0 build 30729
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
I have an FTAM trace that fails to properly decode in Wireshark. I believe
this problem is that there is an issue with the dissection of an implicit octet
strings when the octet string is not primitive (i.e., constructed).
To reproduce:
1) Open ftam.pcap
2) Observe packet 6
Result - ISO 8571 FTAM, Internal Error, zero-byte FTAM PDU
Expected Result - should be able to dissect the FTAM layer of the packet
I've tracked the problem to the dissecting of the PVD-list from
ISO8823-PRESENTATION.asn. The ASN.1 definition of PDV-list includes a CHOICE
of:
CHOICE { ...
octet-aligned [1] IMPLICIT OCTET STRING,
... }
For the trace that fails, a constructed octet string is being used for the
octet-aligned data. To properly dissect this data, the octet string data must
be "reassembled" before sending the tvb buffer to the FTAM dissector (such as
done in the reassemble_octet_string routine).
But, the dissect_ber_choice (packet-ber) dissects and strips the outer tag and
length, and it is the outer tag that has the primitive/constructed (pc)
indication for the contents octets (as per ISO 8825-1/X690, 8.14.4). Since the
pc indication in the outer tag is not conveyed to dissect_pres_T_octet_aligned,
it lacks the information to properly decode the data. Further, the signature of
dissect_ber_octet_string does not support pc for implicitly tagged data.
(Actually, dissect_ber_octet_string always assumes the primitive form of OCTET
STRING as it explicitly sets pc=FALSE when implicit_tag=TRUE.)
It seems to me that to properly resolve this issue would require modifications
to packet-ber.c and asn2wrs.py to support the ability to send the pc flag in
certain implicitly tagged scenarios. (Specifically for the failed pcap file,
dissect_ber_choice would need to send the pc status to
dissect_pres_T_octet_aligned, which can then forward the status to
dissect_ber_octet_string.)
I was able to properly dissect this file by modifying
dissect_pres_T_octet_aligned to call reassemble_octet_string on the data before
calling call_ber_oid_callback. I can provide more details of this fix if
needed. However, this is fix is specific to the PRES-to-FTAM data transfer and
probably would not work in production.
It believe this issue may also apply to implicit bit strings and implicit
strings in general if those strings used the constructed form.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.