Suricata

The following snippet will reliably segfault the worker process:

echo 'EHLO evil.com
HELO evil.com
STARTTLS
RSET
QUIT' | nc mail.example.com 25

(gdb) bt
#0  0x0000000000477f7a in SMTPProcessReply (state=state@entry=0x7fffcc8020c0, f=f@entry=0x175c080, td=td@entry=0x7fffcc4e8f00, pstate=<optimized out>) at app-layer-smtp.c:1029
#1  0x0000000000478bb6 in SMTPParse (thread_data=<optimized out>, input_len=<optimized out>, input=<optimized out>, pstate=<optimized out>, state=<optimized out>,
    f=<optimized out>, direction=1) at app-layer-smtp.c:1378
#2  SMTPParseServerRecord (f=0x175c080, alstate=0x7fffcc8020c0, pstate=<optimized out>, input=<optimized out>, input_len=<optimized out>, local_data=0x7fffcc4e8f00, flags=8 '\b')
    at app-layer-smtp.c:1405
#3  0x0000000000474119 in AppLayerParserParse (tv=tv@entry=0x6ccde80, alp_tctx=<optimized out>, f=f@entry=0x175c080, alproto=<optimized out>, flags=flags@entry=8 '\b',
    input=input@entry=0x7fffcc802432 "220 2.0.0 Ready to start TLS\r\n", input_len=input_len@entry=30) at app-layer-parser.c:1239
#4  0x0000000000431f49 in AppLayerHandleTCPData (tv=tv@entry=0x6ccde80, ra_ctx=ra_ctx@entry=0x7fffcc4e83e0, p=p@entry=0x7fffcc4cff20, f=0x175c080, ssn=ssn@entry=0x7fffcc5b9410,
    stream=stream@entry=0x7fffe09e2e98, data=0x7fffcc802432 "220 2.0.0 Ready to start TLS\r\n", data_len=30, flags=8 '\b') at app-layer.c:661
#5  0x00000000005c4350 in ReassembleUpdateAppLayer (dir=<optimized out>, p=<optimized out>, stream=<optimized out>, ssn=<optimized out>, ra_ctx=<optimized out>, tv=<optimized out>)
    at stream-tcp-reassemble.c:1088
#6  StreamTcpReassembleAppLayer (tv=tv@entry=0x6ccde80, ra_ctx=ra_ctx@entry=0x7fffcc4e83e0, ssn=ssn@entry=0x7fffcc5b9410, stream=stream@entry=0x7fffcc5b9420,
    p=p@entry=0x7fffcc4cff20, dir=dir@entry=UPDATE_DIR_OPPOSING) at stream-tcp-reassemble.c:1145
#7  0x00000000005c50bf in StreamTcpReassembleHandleSegmentUpdateACK (p=0x7fffcc4cff20, stream=0x7fffcc5b9420, ssn=0x7fffcc5b9410, ra_ctx=0x7fffcc4e83e0, tv=0x6ccde80)
    at stream-tcp-reassemble.c:1719
#8  StreamTcpReassembleHandleSegment (tv=tv@entry=0x6ccde80, ra_ctx=0x7fffcc4e83e0, ssn=ssn@entry=0x7fffcc5b9410, stream=0x7fffcc5b94a0, p=p@entry=0x7fffcc4cff20,
    pq=pq@entry=0x7fffcc4e8088) at stream-tcp-reassemble.c:1762
#9  0x00000000005ba6dd in HandleEstablishedPacketToClient (stt=<optimized out>, pq=<optimized out>, p=<optimized out>, ssn=<optimized out>, tv=<optimized out>) at stream-tcp.c:2445
#10 StreamTcpPacketStateEstablished (tv=0x6ccde80, p=0x7fffcc4cff20, stt=0x7fffcc4e8080, ssn=0x7fffcc5b9410, pq=0x7fffcc4e8088) at stream-tcp.c:2682
#11 0x00000000005be26d in StreamTcpStateDispatch (tv=0x6ccde80, p=0x7fffcc4cff20, stt=0x7fffcc4e8080, ssn=0x7fffcc5b9410, pq=<optimized out>, state=<optimized out>)
    at stream-tcp.c:4687
#12 0x00000000005c0171 in StreamTcpPacket (tv=0x6ccde80, p=0x7fffcc4cff20, stt=0x7fffcc4e8080, pq=0x7fffcc4e6fa8) at stream-tcp.c:4876
#13 0x00000000005c0cf0 in StreamTcp (tv=tv@entry=0x6ccde80, p=p@entry=0x7fffcc4cff20, data=<optimized out>, pq=pq@entry=0x7fffcc4e6fa8, postpq=postpq@entry=0x0)
    at stream-tcp.c:5212
#14 0x00000000005475df in FlowWorker (tv=0x6ccde80, p=0x7fffcc4cff20, data=0x7fffcc4e6f80, preq=0x2849850, unused=<optimized out>) at flow-worker.c:245
#15 0x00000000005ce76d in TmThreadsSlotVarRun (tv=tv@entry=0x6ccde80, p=p@entry=0x7fffcc4cff20, slot=slot@entry=0x77e55c0) at tm-threads.c:134
#16 0x00000000005b55d5 in TmThreadsSlotProcessPkt (p=0x7fffcc4cff20, s=0x77e55c0, tv=0x6ccde80) at tm-threads.h:163
#17 PcapFileCallbackLoop (user=0x7fffcc4d0940 "\200\tM\314\377\177", h=<optimized out>, pkt=0x7fffcc4d0e70 "\260\063\246c%\203\204&+عF\201") at source-pcap-file-helper.c:101
#18 0x00007ffff67ccd71 in pcap_offline_read () from /opt/snf/lib/libpcap.so.1
#19 0x00000000005b59a3 in PcapFileDispatch (ptv=0x7fffcc4d0940) at source-pcap-file-helper.c:138
#20 0x00000000005b2905 in ReceivePcapFileLoop (tv=<optimized out>, data=0x7fffcc4d08c0, slot=<optimized out>) at source-pcap-file.c:177
#21 0x00000000005d234b in TmThreadsSlotPktAcqLoop (td=0x6ccde80) at tm-threads.c:360
#22 0x00007ffff4ab3e65 in start_thread () from /lib64/libpthread.so.0
#23 0x00007ffff43c288d in clone () from /lib64/libc.so.6

We initially observed this as part of our vulnerability scanning. The observed traffic looks like this:

> EHLO evil.com
< 220 mail.example.com ESMTP Postfix
> HELO evil.com
< 250-mail.example.com
< 250-PIPELINING
< 250-SIZE 33000000
< 250-VRFY
< 250-ETRN
< 250-STARTTLS
< 250-ENHANCEDSTATUSCODES
< 250-8BITMIME
< 250 DSN
< 250 mail.example.com
> STARTTLS
> RSET
< 220 2.0.0 Ready to start TLS
> QUIT

I'm wondering if it's because it sends RSET without waiting for the 220 response.