Wireshark · Wireshark-bugs: [Wireshark-bugs] [Bug 2380] New: SMTP dissector getting confused by multiple commands/ responses per

[bugzilla-daemon@xxxxxxxxxxxxx]

http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2380

           Summary: SMTP dissector getting confused by multiple
                    commands/responses per packet while pipelining is in
                    effect
           Product: Wireshark
           Version: 0.99.8
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: Major
          Priority: Low
         Component: Wireshark
        AssignedTo: wireshark-bugs@xxxxxxxxxxxxx
        ReportedBy: kai-wireshark-bugs@xxxxxxxxxxxxxx


Created an attachment (id=1581)
 --> (http://bugs.wireshark.org/bugzilla/attachment.cgi?id=1581)
example of broken smtp dissector as discussed

Build Information:
Version 0.99.8 (SVN Rev 24492)

Copyright 1998-2008 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.8, with GLib 2.14.6, with WinPcap (version unknown),
with libz 1.2.3, with libpcre 7.0, with SMI 0.4.5, with ADNS, with Lua 5.1,
with
GnuTLS 1.6.1, with Gcrypt 1.2.3, with MIT Kerberos, with PortAudio V19-devel,
with AirPcap.

Running on Windows XP Service Pack 2, build 2600, with WinPcap version 4.0.2
(packet.dll version 4.0.0.1040), based on libpcap version 0.9.5, without
AirPcap.

Built using Microsoft Visual C++ 6.0 build 8804

Wireshark is Open Source Software released under the GNU General Public
License.

Check the man page and http://www.wireshark.org for more information.

--
The SMTP dissector is getting thoroughly confused when encountering multiple
SMTP commands and replies in the same packet, as it occurs when the client is
using PIPELINING (whether or not permitted by MTA: in this example it IS
permitted)

This behavior appears to be true for all recent versions of Wireshark under
Windows and tshark under any Unix-derivate.

An example output of tshark 0.99.3a under FreeBSD shows the equivalent of what
is visible under Windows versions of Wireshark (tested 0.99.6a and 0.99.8):

  1 2008-03-20 02:42:38.791244  69.56.141.5 -> 67.18.254.6  TCP 36305 > 25
[SYN] Seq=0 Len=0 MSS=1460 TSV=2146823460 TSER=0 WS=7
  2 2008-03-20 02:42:38.792891  67.18.254.6 -> 69.56.141.5  TCP 25 > 36305
[SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1410 WS=2 TSV=3758098048
TSER=2146823460
  3 2008-03-20 02:42:38.856643  69.56.141.5 -> 67.18.254.6  TCP 36305 > 25
[ACK] Seq=1 Ack=1 Win=5888 Len=0 TSV=2146823527 TSER=3758098048
  4 2008-03-20 02:42:38.856860  67.18.254.6 -> 69.56.141.5  TCP [TCP Window
Update] 25 > 36305 [ACK] Seq=1 Ack=1 Win=131412 Len=0 TSV=3758098112
TSER=2146823527
  5 2008-03-20 02:42:48.890770  67.18.254.6 -> 69.56.141.5  TCP [TCP segment of
a reassembled PDU]
  6 2008-03-20 02:42:48.954216  69.56.141.5 -> 67.18.254.6  TCP 36305 > 25
[ACK] Seq=1 Ack=47 Win=5888 Len=0 TSV=2146833623 TSER=3758108147
  7 2008-03-20 02:42:48.954442  67.18.254.6 -> 69.56.141.5  TCP [TCP segment of
a reassembled PDU]
  8 2008-03-20 02:42:49.019569  69.56.141.5 -> 67.18.254.6  TCP 36305 > 25
[ACK] Seq=1 Ack=89 Win=5888 Len=0 TSV=2146833687 TSER=3758108211
  9 2008-03-20 02:42:49.019736  69.56.141.5 -> 67.18.254.6  SMTP Command: EHLO
spooling.theplanet.com
 10 2008-03-20 02:42:49.021535  67.18.254.6 -> 69.56.141.5  SMTP Response:
250-spamshield.org Hello spooling2.theplanet.com [69.56.141.5], pleased to meet
you
 11 2008-03-20 02:42:49.085709  69.56.141.5 -> 67.18.254.6  SMTP Command: MAIL
FROM:<ntss@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx> SIZE=2315
 12 2008-03-20 02:42:49.185394  67.18.254.6 -> 69.56.141.5  TCP 25 > 36305
[ACK] Seq=273 Ack=148 Win=131412 Len=0 TSV=3758108442 TSER=2146833755
 13 2008-03-20 02:42:49.196545  67.18.254.6 -> 69.56.141.5  SMTP Response: 250
2.1.0 <ntss@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>... Sender ok
 14 2008-03-20 02:42:49.265195  69.56.141.5 -> 67.18.254.6  SMTP Message Body
 15 2008-03-20 02:42:49.265499  69.56.141.5 -> 67.18.254.6  SMTP Message Body
 16 2008-03-20 02:42:49.265599  67.18.254.6 -> 69.56.141.5  TCP 25 > 36305
[ACK] Seq=456 Ack=1548 Win=130012 Len=0 TSV=3758108522 TSER=2146833930
 17 2008-03-20 02:42:53.768600  67.18.254.6 -> 69.56.141.5  SMTP Response: 250
2.0.0 m2K6gclh081944 Message accepted for delivery
 18 2008-03-20 02:42:53.836368  69.56.141.5 -> 67.18.254.6  SMTP Command: QUIT
 19 2008-03-20 02:42:53.836534  69.56.141.5 -> 67.18.254.6  TCP 36305 > 25
[FIN, ACK] Seq=1554 Ack=512 Win=8064 Len=0 TSV=2146838504 TSER=3758113025
 20 2008-03-20 02:42:53.836613  67.18.254.6 -> 69.56.141.5  TCP 25 > 36305
[ACK] Seq=512 Ack=1555 Win=131404 Len=0 TSV=3758113093 TSER=2146838504
 21 2008-03-20 02:42:53.840643  67.18.254.6 -> 69.56.141.5  SMTP Response: 221
2.0.0 spamshield.org closing connection
 22 2008-03-20 02:42:53.844774  67.18.254.6 -> 69.56.141.5  TCP 25 > 36305
[FIN, ACK] Seq=557 Ack=1555 Win=131412 Len=0 TSV=3758113101 TSER=2146838504
 23 2008-03-20 02:42:53.905220  69.56.141.5 -> 67.18.254.6  TCP 36305 > 25
[RST] Seq=1555 Len=0
 24 2008-03-20 02:42:53.910438  69.56.141.5 -> 67.18.254.6  TCP 36305 > 25
[RST] Seq=1555 Len=0

A manual review shows that packet 11 does not solely contain the MAIL FROM
command, but also the RCPT TO and DATA commands.

None of these additional requests are displayed by Tshark or in Wireshark's
"Packet Details" display.

Likewise, packet 13 contains the MTA's replies to not just MAIL FROM, but also
the RCPT TO and DATA commands, the latter 2 of which are, again, not displayed.

Finally, in packet 14 (in Windows versions only), the first line of the header
starting with "Return-path:..." is wrongly dissected as a SMTP Command:
- The "Retu" string is displayed as the command,
- the rest of the line ("rn-path....") as the Request parameter.

Wireshark's idea of what the "SMTP Message Body" is appears to be "everything
between DATA and the terminating .".
Suggested enhancement, while someone is fixing the dissector: recognize and
distinguish within the DATA section between RFC2822 mail headers and
message-body separately. Might split into separate bug.

Attached is the pcap file for this example.


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