An app-layer-state comparison that can never hold - mode '>' at or beyond
the completion state, or mode '<' at the starting state - can never match.
Both are fatal at rule load, so reject them at parsing.
The LTE (<hook) form at the first state (progress 0) is accepted and is
equivalent to the plain hook form: there are no prior states to auto-accept.
Derive the completion state from the direction the keyword resolved in
instead of the rule's flags, and document the new load time rejections.
Ticket: #8944.
State table and failure/completion semantics for the
per-direction scale (banner/kex/session, done never reported),
the removed banner_wait_eol state and legacy hook names, the new
eve ssh error/state fields, and the transactions/lua/upgrade
examples - all updated to match.
Ticket: #9046.
Pygments 2.21 lexes "x < 0 or x > y" in Lua as a Lua 5.4 variable
attribute (e.g. "<const>"), producing an error token on the "0". Sphinx
reports this as a highlighting failure warning, and as the PDF build
treats warnings as errors, "make dist" fails while building the PDF.
Reorder the comparisons so the Lua example is lexed correctly. The logic
of the example is unchanged.
SWF depth settings were previously limited only to values representable by
uint32_t. This is not sufficient for the buffer-size calculations performed
during SWF decompression.
The decompressed output requires an additional 8-byte FWS header. The
inspection buffer also grows by doubling a uint32_t size, so a required buffer
larger than 2 GiB can cause the growth calculation to wrap.
For LZMA input, a synthesized 13-byte header to the compressed
data is used. The configured compressed-data limit must leave room for this header.
This patch applies the following upper limits:
- decompress-depth: 2147483640 bytes
(2 GiB minus the 8-byte FWS header)
- compress-depth: 4294967282 bytes
(UINT32_MAX minus the 13-byte LZMA header
Ticket: #8914
SWF FileLength was used to determine the decompressed buffer size when
decompress-depth is set to zero, but this field can be manipulated and it can
lead to evasion.
This patch treat FileLength as metadata, the length bytes are just copied, and
when decompress-depth is set to 0, a maximum value of 50MB is considered for
the decompressed buffer.
Ticket: #8855
Add a note to the pcre extraction section stating that a flow: capture
is dropped when the packet is inspected without a flow, and that such a
packet still alerts.
ICMPv4 error messages are one way to get such a packet: FlowCreateCheck
returns false for them, while DecodeICMPV4 has already set p->payload,
so they reach the detection engine with something to inspect and nowhere
to store a flow variable. A packet the flow engine could not give a flow
to once the memcap was reached and no used flow could be reclaimed is
the other.
The pkt: and alert: scopes described in the same section are unaffected,
because a packet variable is stored on the packet and an alert variable
on the alert.
Issue: 8862
Record that << and >> yield 0 when rvalue is 64 or more, beside the
existing note about division by zero. A shift count can come from a
byte_extract variable, so the rule text alone does not say which
counts land in that case.
Issue: 8845
Introduce the tcp.session: keyword that accepts a comma-separated subset
of {setup, established, closing} and matches packets whose TCP session
state falls within the named phases.
This lets a rule writer cover the full TCP lifecycle in one rule instead
of separate flow:not_established + flow:established rules.
Changes:
- New detect-tcp-session.{c,h} with parser, match function, unit tests
- Register DETECT_TCP_SESSION in detect-engine-register.{c,h}
- Add to Makefile.am source list
- Extend engine-analyzer text output for tcp.session:
- Extend firewall.json keyword_info with tcp_session phase values
- Update flow-keywords.rst documentation
- Require TCP protocol and SIG_FLAG_REQUIRE_PACKET at setup
Ticket: 7704
This keyword accepts a boolean value and issues a check against the
header flags in a respective direction per transaction to check if
the current PDU is fragmented or not.
The classification criteria is very clear for UDP: flags 0x04 have to be
set on the PDU explicitly marking it fragmented.
The classification criteria for TCP is a bit ambiguous in the RFC but
with the current implementation in Suricata only honoring the types
REQUEST, BIND, ALTER_CONTEXT, following criteria is used.
PFC_FIRST_FRAG && PFC_LAST_FRAG set => it's a complete PDU; unfragmented
fragmented otherwise.
ref: https://pubs.opengroup.org/onlinepubs/9629399/chap12.htm
Feature 8736
Extend the app-layer-protocol keyword to accept a pipe-separated list of
protocol values, so a single rule can match any of several protocols:
app-layer-protocol:[!]<proto1>|<proto2>[|...][,<qualifier>]...;
A non-negated list matches when the flow's protocol equals any listed value
(OR); a negated list matches when it equals none of them (NOR). The
single-value form and the trailing mode qualifier are unchanged.
Matching keeps the historical AppProtoEquals() equivalences by default
(dns/doh2, http/http1/http2, dcerpc/smb, ...). An `exact` qualifier selects
strict identity matching with no equivalences and no http umbrella; it
combines with a direction mode in any order. Because a flow is never the
generic ALPROTO_HTTP, `http,exact` is rejected at load.
Values are expanded once at rule load into an effective match-set bitmask, so
the per-packet match is a single bitmask test. Single-value rules remain
prefilterable; multi-value rules are excluded from prefiltering and an
explicit prefilter on them is rejected. Conflicting keyword combinations
(duplicate or overlapping negations, mixed positive/negated) are rejected at
load. Engine-analysis reports the effective match set.
Ticket: 7705
Support STOU on the FTP data channel.
With STOU a filename is optional. If no filname is provided, use
"<stou>". The server does respond with the filename to use, but there
can be a race condition in getting this filename and setting up file
storage before data starts flowing.
Ticket: #8664
Add user-facing documentation for the xor transform's 'extract <nbytes>
<offset>' syntax and offset parameter in rules/transforms.rst.
Add a devguide section (devguide/extending/detect/transforms.rst)
covering the detection pipeline execution order, how transforms run
before detection-time keywords, and how xor reads key bytes directly
from the raw buffer at a specified position and width. Explains how
the engine deduplicates inspection buffers for rules with variable
keys at different buffer positions.
Issue: 8671
Extend the xor transform to accept a variable-position key using
the 'extract <nbytes> <offset>' syntax. The engine reads <nbytes> bytes
at buffer position <offset> at transform time.
The optional 'offset' parameter specifies where XOR decoding
starts in the buffer; bytes before that position are left unchanged.
Syntax:
xor:"<hex_key>"
xor:extract <nbytes> <offset>
xor:offset <N>,"<hex_key>"
xor:offset <N>,extract <nbytes> <offset>
Variable-key helpers (VariableKeyLocation, variable_key_bytes,
parse_key_location, strip_keyword_prefix) are imported from the new
varkey module.
The variable key bytes are copied out of the inspection buffer before
decoding, so an in-place transform cannot corrupt the key when the key
region overlaps the decoded range.
Issue: 8671
toggle command is not used by any major rulesets and increases the state
complexity of flowbits management. Also, all operations can be carried
out with the combination of other available commands. So, remove it.
Task 8595
Ticket: 7929
Builds a vector of the reason code in a tx to do so,
except if we use the default "any", where we do not append
to the vector, but just run detection while iterating
Shivani Bhardwaj
Juliana Fajardini
Philippe Antoine
Victor Julien
William Ling
Jason Ish
Giuseppe Longo
Jeff Lucovsky
Yash Datre
Shivani Bhardwaj
Antoine Abou Faysal
Giuseppe Longo