Project

General

Profile

Actions

Security #6279

closed

Crash in SMTP parser during parsing of email

Added by Simen Lybekk over 1 year ago. Updated about 1 year ago.

Status:
Closed
Priority:
Normal
Target version:
Affected Versions:
Label:
CVE:
Git IDs:
Severity:
HIGH
Disclosure Date:

Description

During testing of Suricata 7.0, we've noticed that Suricata occationally exits due to issues with SMTP traffic.

- SCMd5Update+0x00000013
- MimeDecParseLine+0x00000101
- SMTPProcessRequest.isra.15+0x000004ba
- SMTPPreProcessCommands.isra.16+0x0000010b
- SMTPParse+0x00000157
- AppLayerParserParse+0x00000343

The bug has been reproduced on suricata-7.0.0 (21ec99aa7).
Quick testing with SMTP applayer set to detection only and the file logger being configured to force MD5 hashing suggests the issue isn't tied directly to the new Rust MD5 hashing.

We have acquired a copy of the traffic that triggers the flow, and produced a minimal PCAP for reproducing this.
Removing either the Received header or the PIPELINING feature flag stops the crash.


Files

poc-security-6279.pcap (1.53 KB) poc-security-6279.pcap Simen Lybekk, 08/25/2023 02:26 PM

Subtasks 1 (0 open1 closed)

Security #6289: Crash in SMTP parser during parsing of email (6.0.x backport)ClosedPhilippe AntoineActions

Related issues 1 (1 open0 closed)

Related to Suricata - Optimization #3591: fuzz: target with pcap, rules and yamlIn ProgressPhilippe AntoineActions
Actions #1

Updated by Shivani Bhardwaj over 1 year ago

  • Status changed from New to Assigned
  • Assignee changed from OISF Dev to Shivani Bhardwaj
Actions #2

Updated by Jason Ish over 1 year ago

  • Tracker changed from Bug to Security
  • Private changed from No to Yes
  • Severity set to MODERATE
Actions #3

Updated by Simen Lybekk over 1 year ago

Actions #4

Updated by Jason Ish over 1 year ago

I am able to reproduce, but not in the context of any filestore configuration. Instead by enabling the body-md5 features of the SMTP parser.

Actions #5

Updated by Simen Lybekk over 1 year ago

Jason Ish wrote in #note-4:

I am able to reproduce, but not in the context of any filestore configuration. Instead by enabling the body-md5 features of the SMTP parser.

That is correct.

I was trying to say that it's not happening due to MD5 hashing in general, and that this is the only code path we've gotten the crash for.
The comment was from before we had a reproduction PCAP and associated core dump, just the libunwind callstack.

Actions #6

Updated by Jason Ish over 1 year ago

Can this pcap end up in public tests?

Actions #7

Updated by Jason Ish over 1 year ago

So quick analysis.. At util-decode-mime.c:2355, SCMd5Update is being called with a NULL md5 context. SCMd5Update has the expectation that its self object is valid.

So while this is a state-machine type error in the MIME decoding, I'm thinking some assertions on the Rust side are also in order. Suricata will still crash, but it'll be absolutely clear that the contract between the function and the caller wasn't honored.

Actions #8

Updated by Philippe Antoine over 1 year ago

NULL deference stack trace is

AddressSanitizer:DEADLYSIGNAL
=================================================================
==32122==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000058 (pc 0x000109e933a8 bp 0x70000f4ef9f0 sp 0x70000f4ef9c0 T13)
==32122==The signal is caused by a READ memory access.
==32122==Hint: address points to the zero page.
    #0 0x109e933a8 in SCMd5Update hashing.rs:144
    #1 0x109c5d75a in MimeDecParseLine util-decode-mime.c:2569
    #2 0x1098fe22b in SMTPProcessRequest app-layer-smtp.c:1299
    #3 0x1098fc22f in SMTPPreProcessCommands app-layer-smtp.c:1393
    #4 0x1098fabc0 in SMTPParse app-layer-smtp.c:1465
    #5 0x1098f6d22 in SMTPParseClientRecord app-layer-smtp.c:1506
    #6 0x1098f087c in AppLayerParserParse app-layer-parser.c:1407
    #7 0x10982c039 in AppLayerHandleTCPData app-layer.c:773
    #8 0x109c13d06 in StreamTcpReassembleAppLayer stream-tcp-reassemble.c:1391
    #9 0x109c18804 in StreamTcpReassembleHandleSegment stream-tcp-reassemble.c:1997
    #10 0x109bc65d3 in StreamTcpStateDispatch stream-tcp.c:5236
    #11 0x109bb4eaf in StreamTcpPacket stream-tcp.c:5433
    #12 0x109be7a97 in StreamTcp stream-tcp.c:5745
    #13 0x109b0636e in FlowWorkerStreamTCPUpdate flow-worker.c:391
    #14 0x109b03ff5 in FlowWorker flow-worker.c:607
    #15 0x109c38990 in TmThreadsSlotVar tm-threads.c:469
Actions #9

Updated by Philippe Antoine over 1 year ago

  • Status changed from Assigned to In Review
  • Assignee changed from Shivani Bhardwaj to Philippe Antoine
  • Target version changed from TBD to 7.0.1
  • Label Needs backport, Needs backport to 6.0 added

Gitlab MR

Actions #10

Updated by OISF Ticketbot over 1 year ago

  • Subtask #6289 added
Actions #11

Updated by OISF Ticketbot over 1 year ago

  • Label deleted (Needs backport, Needs backport to 6.0)
Actions #12

Updated by Simen Lybekk over 1 year ago

Jason Ish wrote in #note-6:

Can this pcap end up in public tests?

Sure, that's fine

Actions #13

Updated by Philippe Antoine over 1 year ago

  • Severity changed from MODERATE to HIGH

I think this is a feature "disabled by default Tier 1", so HIGH severity

Actions #14

Updated by Victor Julien about 1 year ago

  • Status changed from In Review to Resolved
Actions #16

Updated by Philippe Antoine about 1 year ago

Actions #17

Updated by Victor Julien about 1 year ago

  • Private changed from Yes to No
Actions

Also available in: Atom PDF