Wireshark-bugs: [Wireshark-bugs] [Bug 6470] New: tshark badly interprets RFC2554 (SMTP authentic
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6470
Summary: tshark badly interprets RFC2554 (SMTP authentication)
Product: Wireshark
Version: 1.4.9
Platform: x86
OS/Version: Fedora
Status: NEW
Severity: Normal
Priority: Low
Component: TShark
AssignedTo: bugzilla-admin@xxxxxxxxxxxxx
ReportedBy: franta@xxxxxxxxxxx
Created an attachment (id=7265)
--> (https://bugs.wireshark.org/bugzilla/attachment.cgi?id=7265)
both here included outputs (without and with display filters)
Build Information:
TShark 1.4.9
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 GLib 2.26.0, with libpcap 1.1.1, without libz, without
POSIX capabilities, without libpcre, with SMI 0.4.8, without c-ares, without
ADNS, with Lua 5.1, without Python, with GnuTLS 2.8.6, with Gcrypt 1.4.5, with
MIT Kerberos, with GeoIP.
Running on Linux 2.6.35.14-96.fc14.i686.PAE, with libpcap version 1.1.1.
Built using gcc 4.5.1 20100924 (Red Hat 4.5.1-4).
--
when decode pcap file previously captured by "tcpdump -w file.pcap port 25"
command, then "tshark -n -r file.pcap" output looks like (I cutted out only
authentication part):
166 44.815436 85.70.171.14 -> 77.75.72.48 SMTP C: AUTH LOGIN
167 44.815560 77.75.72.48 -> 85.70.171.14 SMTP S: 334 VXNlcm5hbWU6
168 44.831403 85.70.171.14 -> 77.75.72.48 SMTP C: am9lc21pdGg=
169 44.831465 77.75.72.48 -> 85.70.171.14 SMTP S: 334 UGFzc3dvcmQ6
170 44.846178 85.70.171.14 -> 77.75.72.48 SMTP C: aWVLMlF1YWg=
171 44.886176 77.75.72.48 -> 85.70.171.14 TCP 25 > 16066 [ACK] Seq=342 Ack=73
Win=5840 Len=0
172 45.474313 77.75.72.48 -> 85.70.171.14 SMTP S: 235 2.0.0 OK Authenticated
which is fine. When process same file using display filter fields, with
command:
'tshark -r file.pcap -n -T fields -e tcp.srcport -e tcp.dstport -e ip.src -e
ip.dst -e smtp.req.command -e smtp.req.parameter -e smtp.response.code -e
smtp.rsp.parameter -R "smtp.req == 1 || smtp.rsp == 1"', then output is as:
16066 25 85.70.171.14 77.75.72.48 AUTH LOGIN
25 16066 77.75.72.48 85.70.171.14 334 VXNlcm5hbWU6
16066 25 85.70.171.14 77.75.72.48 am9l 21pdGg=
25 16066 77.75.72.48 85.70.171.14 334 UGFzc3dvcmQ6
16066 25 85.70.171.14 77.75.72.48 aWVL lF1YWg=
25 16066 77.75.72.48 85.70.171.14 235 2.0.0 OK
Authenticated
where is visible that client responses are ruptured at something as
smtp.req.command and smtp.req.parameter with missing character at fifth
position
(e.g. client response "am9lc21pdGg=" is treated as smtp.req.command="am9l" and
smtp.req.parameter="21pdGg=" (and letter "c" isn't in either part).
This should be probably somehow handled better. Or, maybe, constitute another
SMTP display filter field, which wil display full decoded SMTP line as in case
when not using display filter (in this case it would display "C:
am9lc21pdGg=").
Maybe same solution would be sufficient in case of bug no. 6446 (IMAP display
filter) and maybe other protocols - after all, without using display filters &
field names, tshark decodes protocol correctly and for lot of cases (including
my own) it is sufficient, I only want display some additional fields from
TCP/IP/Ethernet layer.
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
