The Deprecation note on Syslog was partly conveying the opposite
message, and we were missing a deprecation notice on the Syslog output
section.
(cherry picked from commit 926fde859e)
... to account for midstream sessions.
Commit 497394e removed inspection of app-proto txs for packets
without an established TCP connection. But this meant that the
first packet seen in a session pick mid-stream could go without
inspection (previous bug 5510 seemed to point towards this behavior,
too).
If a flow has more packets, the stream will be inspected as part of
the upcoming packets and this would go unnoticed. In a single-packet
flow, however, the inspection for the packed would be skipped. Although
this might not affect alerts -- as they could be processed as part of
the flow timeout logic, the actual traffic could be evaded in IPS, in
case of a drop rule.
From the above, the most visible scenario is when there is only one packet on the flow,
as then the engine doesn't have "more time" to pick-up real-packets to
inspect for that given flow. But certain tests show that this can also
happen for more than one packet scenarios: there will be one less drop
event, or traffic from a packet that should have been already dropped
will be logged.
This led to the possibility of a real packet not being blocked, in IPS,
or matched against rules, as the corresponding portion of the stream
was only inspected later, as part of the stream/flow-timeout logic.
To ensure that we correctly flag the first packet seen for a given mid-stream
session, we must check for the session state and existance *after* we
have dealt with TCP flags and state.
Related to
Bug #5510
As part of
Bug #5180
(cherry picked from commit bd76c29ed8)
Adding the directory "install" to EXTRA_DIST, actually triggers make
to run "make install", which is not what we want. Instead, avoid this
magic keyword and list the files in the install directory
individually.
If the user doesn't have permission to install files to the prefix,
like "/usr", then "make dist" can fail. Worse, even they do have
permission to write into the prefix, a "make dist" will install files
there when it shouldn't.
Ticket: #8279
(cherry picked from commit 2defd5ae5a)
cargo audit reports this security issue with the time crate but Suricata
remains unaffected as no influenced fn is used by Suricata.
Advisory: https://rustsec.org/advisories/RUSTSEC-2026-0009
The MSRV for newer time crate versions are higher than the MSRV for
Suricata right now: 1.75.0
Hence, the best course of action is to suppress this warning.
Ticket: 8269
(cherry picked from commit 11b2860f23)
When the decoder finds a packet with wrong IP version for
IPv4|IPv6-in-IPv6 tunnels, it would set an event, but wouldn't flag the
packet invalid. This fixes that.
Bug #7964
(cherry picked from commit ee7f01c83f)
Adds a chapter indicating what are the main steps when adding exception
policies, how is it possible to extend them, as well as main aspects and
files to consider when doing so.
Task #5612
(cherry picked from commit 48b15ac152)
Some drivers (e.g. BNXT) fail to report stats after the device is
stopped. Move stats collection (DPDKDumpCounters and PrintDPDKPortXstats)
to run before rte_eth_dev_stop() in HandleShutdown.
Also change PrintDPDKPortXstats error handling from FatalError to
graceful return since stats collection failures during shutdown
should not crash the application.
The commit removes ThreadExitPrintStats callback as the function had no
useful features after the stats were moved.
Ticket: 8252
(cherry picked from commit 27f398b5f2)
Move error logging from util-mpm-hs to reuse it in util-spm-hs as it
has proper hs_compile error handling.
Bug: #8146.
(cherry picked from commit 11073a0190)
Redmine ticket: #8261
According to [1], the within pointer (if combined with distance)
includes the distance pointer, which is not clearly visible in the
graphic.
Fixed this in a new graphic by some GIMP arts.
PS: Special thanks to one of our team members Annika C. for initially
spotting this!
[1] https://forum.suricata.io/t/is-within-affected-by-distance/1688
(cherry picked from commit 69eb567dea)
When not sandboxed, a script can get access to the metatable and call
`.__gc` with an invalid value like nil, causing a NULL pointer dereference
in Suricata.
Ticket: #8248
(cherry picked from commit 5d61f5253d)
warning: called `unwrap` on `rd.pipe` after checking its variant with `is_some`
--> src/smb/smb1.rs:858:28
|
857 | if rd.pipe.is_some() {
| -------------------- help: try: `if let Some(<item>) = rd.pipe`
858 | let pipe = rd.pipe.unwrap();
| ^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.93.0/index.html#unnecessary_unwrap
= note: `#[warn(clippy::unnecessary_unwrap)]` on by default
(cherry picked from commit 02cb0f2ac2)
Ticket: 8224
We sometimes set events to the last tx, so we do not have access
to the HtpTxUserData in the caller HTPHandleError
(cherry picked from commit c333b28719)
When in a `base64_decode`-`base64_data` pair the decode was depending
on another match through the relative option, the `buffer_offset` would
be updated to the relative position of the previous match. During the
`base64_data` phase, a relative match would use that offset even though
the match happened in a new buffer.
Example::
http.request_body; content:"|27|"; \
base64_decode:relative; \
base64_data; content:"|ff ff ff ff|"; within:16;
This use of the `buffer_offset` is incorrect as that value is relative
to a buffer and the `base64_data` points to a new buffer.
This patch addresses this by resetting DetectEngineThreadCtx::buffer_offset
before inspecting `base64_data`.
Bug: #7842.
(cherry picked from commit 5f92a6cac3)
Firewall rules were supposed to also load when using a config like
##
## Suricata as a Firewall options (experimental)
##
firewall:
# toggle to enable firewall mode
enabled: yes
# Firewall rule file are in their own path and are not managed
# by Suricata-Update.
rule-path: /etc/suricata/firewall/
# List of files with firewall rules. Order matters, files are loaded
# in order and rules are applied in that order (per state, see docs)
rule-files:
- firewall.rules
But they were not because of a missing check.
Bug: #8206.
(cherry picked from commit 2a2b98650b)
These were previously logged correctly only for nfs v3
Now, the correct opcodes are used for v2 and v4 as well
Ticket: 8222
(cherry picked from commit 1832b50506)
TLS parsers use x509-parser crate which parses X.509 certificates that
use ASN.1 DER encoding that can allow arbitrary byte sequences. An
attacker could inject null byte in a certificate anywhere to stump the
common language parsers terminating the string at a null byte leading to
a bypass of a possibly malicious certificate.
So far, the rust TLS parser for "subjectaltname" used a pattern that involved:
-> Get ASN.1 DER encoded raw data from the x509-parser crate
-> Convert this raw data to a decoded string (Rust)
-> Convert the Rust string to CString
-- The problem lies here. CString only accepts proper strings/byte
buffers and converts it into an owned C-compatible, null-terminated
string. However, if any null byte occurs in the string passed to the
CString then it panics.
In the rust TLS parser, this panic is handled by returning NULL.
This means that the parser will error out during the decoding of the
certificate. However, Suricata must be able to detect the null byte
injection attack being an IDS/IPS.
Hence, replace all such string patterns w.r.t. TLS SAN with a byte
array.
Bug 7887
(cherry picked from commit 1d7b0d9b7a)
TLS parsers use x509-parser crate which parses X.509 certificates that
use ASN.1 DER encoding that can allow arbitrary byte sequences. An
attacker could inject null byte in a certificate anywhere to stump the
common language parsers terminating the string at a null byte leading to
a bypass of a possibly malicious certificate.
So far, the rust TLS parser for "issuerdn" used a pattern that involved:
-> Get ASN.1 DER encoded raw data from the x509-parser crate
-> Convert this raw data to a decoded string (Rust)
-> Convert the Rust string to CString
-- The problem lies here. CString only accepts proper strings/byte
buffers and converts it into an owned C-compatible, null-terminated
string. However, if any null byte occurs in the string passed to the
CString then it panics.
In the rust TLS parser, this panic is handled by returning NULL.
This means that the parser will error out during the decoding of the
certificate. However, Suricata must be able to detect the null byte
injection attack being an IDS/IPS.
Hence, replace all such string patterns w.r.t. TLS IssuerDN with a byte
array.
Bug 7887
(cherry picked from commit f025e07191)
TLS parsers use x509-parser crate which parses X.509 certificates that
use ASN.1 DER encoding that can allow arbitrary byte sequences. An
attacker could inject null byte in a certificate anywhere to stump the
common language parsers terminating the string at a null byte leading to
a bypass of a possibly malicious certificate.
So far, the rust TLS parser for "Subject" used a pattern that involved:
-> Get ASN.1 DER encoded raw data from the x509-parser crate
-> Convert this raw data to a decoded string (Rust)
-> Convert the Rust string to CString
-- The problem lies here. CString only accepts proper strings/byte
buffers and converts it into an owned C-compatible, null-terminated
string. However, if any null byte occurs in the string passed to the
CString then it panics.
In the rust TLS parser, this panic is handled by returning NULL.
This means that the parser will error out during the decoding of the
certificate. However, Suricata must be able to detect the null byte
injection attack being an IDS/IPS.
Hence, replace all such string patterns w.r.t. TLS Subject with a byte
array.
Bug 7887
(cherry picked from commit 77c21b05d2)
16384 is used as the max, but a configuration parameter has been
provided. The reason for setting an upper bound is that bit flags can
create a memory amplification as we parse them into individual data
structures.
Ticket: #8181
(cherry picked from commit 3a32bb5743)
Lower the number of unreplied requests from 500 to 32 to consider a
flood. At the very least this is an anomaly given the DNP3 spec mentions
that DNP3 should only have one outstanding request at a time, with an
exception for unsolicited responses, so in practice no more than 2
should be seen.
Additionally make this value configurable by introducing the max-tx
parameter.
Ticket: #8181
(cherry picked from commit a16f087b93)
Complete is a flag used to tell if the message was completely parsed,
as not all messages may be completely parsed if we don't know all
their objects. However, they are still "done".
In the alstate-progress callback, check the done flag, not the
complete flag.
Ticket: #8181
(cherry picked from commit d61eef9a8a)
DCERPC parsers had no upper bounds when it came to extending the stub
data buffer. Traffic can be crafted to bypass some internal parser
conditions to create an indefinite buffering in the stub_data array that
can make Suricata crash.
Add a default limit of 1MiB and make it configurable for the user.
Security 8182
Co-authored-by: Philippe Antoine <pantoine@oisf.net>
(cherry picked from commit e412215af9)
Ticket: 8201
Limits the quadratic complexity if each packet, restarting the
header parsing, just adds a new folded line.
This was previously bounded by the configurable max header length
(cherry picked from commit fa5a4a994a)
So far, the alert queue was expanded by doubling in size w/o any
boundary checks in place. This led to situations where doubling
the alert_queue_capacity meant overflow of the very same value
stored in det_ctx.
This led to heap-use-after-free in some conditions where
det_ctx->alert_queue_capacity overflowed.
Fix this by capping the max of alert_queue_capacity by checking if its
expansion could result in an overflow.
Security 8190
(cherry picked from commit ac1eb39418)
Sven Cuyt
Victor Julien
Juliana Fajardini
Philippe Antoine
Jason Ish
Shivani Bhardwaj
Lukas Sismis
Sergey Zhidkih
Andreas Dolp
Abhijeet Singh