]> git.ipfire.org Git - thirdparty/suricata.git/commit
smtp: trigger raw stream inspection
authorShivani Bhardwaj <shivanib134@gmail.com>
Mon, 30 Jun 2025 10:24:35 +0000 (15:54 +0530)
committerVictor Julien <victor@inliniac.net>
Mon, 30 Jun 2025 18:44:59 +0000 (20:44 +0200)
commite8f78da123c51b055f911d28d31f6b5dedbb4c0f
tree13abe6899f8d682c39d4ac05e5c2473361193ab8
parent379f04cdd1773c9efad413a583c18b8587b54f73
smtp: trigger raw stream inspection

Internals
---------
Suricata's stream engine returns data for inspection to the detection
engine from the stream when the chunk size is reached.

Bug
---
Inspection triggered only in the specified chunk sizes may be too late
when it comes to inspection of smaller protocol specific data which
could result in delayed inspection, incorrect data logged with a transaction
and logs misindicating the pkt that triggered an alert.

Fix
---
Fix this by making an explicit call from all respective applayer parsers to
trigger raw stream inspection which shall make the data available for inspection
in the following call of the stream engine. This needs to happen per direction
on the completion of an entity like a request or a response.

Important notes
---------------
1. The above mentioned behavior with and without this patch is
affected internally by the following conditions.
- inspection depth
- stream depth
In these special cases, the inspection window will be affected and
Suricata may not consider all the data that could be expected to be
inspected.
2. This only applies to applayer protocols running over TCP.
3. The inspection window is only considered up to the ACK'd data.
4. This entire issue is about IDS mode only.

SMTP parser can handle multiple command lines per direction. Appropriate calls
to trigger raw stream inspection have been added on succesful parsing of each
request line and response line.

For the requests, the call to trigger inspection has been added in the
beginning rather than the completion of transactions. This does not
affect the inspection as it is actually triggered in the following call.
This covers the case for anomaly as well. There are two benefits for
this:
- immediate inspection for anomalous data
- flushing of the anomalous data making next data's inspection cleaner

Bug 7783
src/app-layer-smtp.c