NotRequest and NotResponse event type have never been used.
Unsolicited is also unused, however there is a rule for it so removing
support would be a breaking change at this time.
Since snmp txs are created at progress 1 which is the completion,
this does not change detection, except allowing firewall mode
to use these keywords with generic hook like
snmp:request_complete
Ticket: 8395
Ticket: 8395
For protocols where tx are complete at start, that is
the `tx_get_progress` function returns 1 inconditionnally,
we can use the progress 1, not losing time on detection in ips
mode, and getting ready for firewall mode
For the other protocols (where a tx needs both a request and response
for instance), keep progress 0 as was the case before
Wrap the EVE callback handler with a Rust friendly variant that allows
the user to register a callback as a closure which is provided an
already wrapped JsonBuilder object.
Ticket: #8477
Ticket: 8413
RFC 6455 Section 5.4 states
Control frames (see Section 5.5) MAY be injected in the middle of
a fragmented message.
Control frames are identified by opcodes where the most significant
bit of the opcode is 1.
unicode-segmentation (used by rustyline) was updated from 1.12.0 to
1.13.1 earlier and requires a newer version of Rust. Pin to 1.12.0 which
works with Rust 1.75.0.
So that we can log and detect on interface uuids, even if
AlterContext packets change one of the contexts, but other contexts
are still used after it in request/responses
Ticket: 8378
Ticket: 8375
logger already read this variable but it was never set, and
the rust compiler did not warn about this
Allows to log the interface uuid when ctx_id > 0
Wireshark filter for related pcaps
dcerpc.cn_ctx_id > 0 && dcerpc.pkt_type == 0
And consistently use the CARGO_ENV for all cargo calls.
This allows a user to point to rust binaries that are not on their
path just during ./configure, for example:
PATH=/usr/lib/rust-1.89/bin:$PATH ./configure ...
The full path to rustc and rustdoc will now be used, as discovered in
the PATH without the user have to carry the path over to the "make"
command. This was already done for cargo.
Related to ticket: #8381
Ticket: 8289
If stream.reassembly.depth is unlimited,
an attacker controlling the 2 sides of a communication going through Suricata
can send a transition with an infinite number of headers, until suricata OOMs
Solution is to offer a configuration option to bound the number
of HTTP2 frames we store in a HTTP2 transaction, and produce an
anomaly if this bound is crossed
Ticket: 8292
When we have buffered something in ctx.decoded_line,
we already looked for '\n' in it, so we do not need to run it again
Otherwise, callers that supply mime_smtp_find_url_strings with
a few bytes at a time without "\n", have a quadratic
complexity
Bindgen the Rust bindings to the C JsonBuilder API along with the rest
of the Rust bindings to C. Breaking it out was probably the wrong
idea.
This should make it easier, and more correct to bindgen C functions
that use SCJsonBuilder types.
It's not possible to use all the functions and macros from the ffi crate
in the main Suricata crate, as there are conditionals around when
running in test mode, and "cargo test" doesn't propagate the "cfg(test)"
to test crates.
Which for now means duplicating the macros and some functions.
A plugin can now create a "Plugin" struct with Rust strings. The
`into_raw` method converts it to a raw pointer suitable for returning
during plugin registration.
Mostly a copy of Suricata core's logging wrappers into the ffi crate.
These are not yet used by Suricata-core as they do require the
Suricata library to be available, which is not the case with tests. And
the `cfg(test)` parameter is not passed through to sub-crates.
However, this does allow a plugin (or library) to call the logging
macros without depending on the "suricata" crate.
Ticket: #7666
This crate is for Rust wrappers around the -sys crate which includes
only raw bindings. This is the place to add nice wrappers around those
bindings, however it should remain clear of dependencies on the main
Suricata core crates.
Ticket: #7666
There is an unfortunate side-affect that one has to read
output-eve-bindgen.h for the documentation on this type, however, I
think we can resolve that in time.
Previously we were boxing a u8 and returning it as a pointer to a
boolean. While this is probably not an issue itself, the value 2 was
allowed to be converted to a boolean, which is undefined behavior in
Rust.
and bindgen it to rust
Will make easier the bindgen of RustParser structure which uses
a callback which uses AppLayerTxData
Move also the free function to C SCAppLayerTxDataCleanup
As suricata-sys crate defines AppLayerTxData for rust,
It must itself implement the Drop trait, and thus,
We need to define a feature surest
and bindgen it to rust
Will make easier the bindgen of RustParser structure which uses
a callback which uses AppLayerResult
Keep From<> impl in sys crate that defines it
and bindgen it to rust, and use default trait instead of new
Will make easier the bindgen of RustParser structure which uses
a callback which uses AppLayerStateData
Unittests test_parse_bind_pdu_infinite_loop and
test_parse_bindack_pdu_infinite_loop seem to have artificially made up
header which does not hold up to the strict calculations enforced by the
parser now. Their headers mark the fraglens as 64 and 72 respectively
which are not enough to hold the kind of bind(ack) items that are expected.
It worked so far as the parser passed the entire input slice around but
with the bugfix for issue 7546, the input passed around is strictly
restricted to the fraglen parsed in the header.
Bug 7546
So far, the fraglen defined in the header was used inconsistently in
certain places to define bounds on input length. Make it consistent by
making sure that only a slice up until fraglen is passed around as that
is the maximum length the fragment should have.
With the help of Applayer::incomplete API, the case when the
stream_slice passed to the parser is smaller than the header defined
fraglen is already handled.
Bug 7546
The parser could receive an input that consists of arbitrary data post
gap. This is handled in the beginning of the fn handle_input_data.
However, the rest of the calculation does not take into account the
bytes that were consumed at this stage. Fix the indices and calculations
to consider a new DCERPC fragment beginning post these consumed bytes.
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
Header handling is wrong in the case
packet A to server is fragmented (return AppLayerResult::incomplete)
packet B is to client, but uses the header of the to_server packet
Bug 7547
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>
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
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
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
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
The functionality of "both" can already be easily achieved by using both
"toclient" and "toserver" in a rule. This just adds the ease of
expression in rule. As it is added now, check the direction for the
pre-existing users of direction as well.
As we want the last tx
Ticket: 8156
The generic function AppLayerParserGetTxCnt calls for HTTP1
Transactions.size()
This function has some specific code, as we may have pre-created
a tx that we do not want to count.
This used to get the last tx by iterating over all the transactions
waiting to find the one with max index.
So, instead of using the Transactions.get function, we get the last
tx out of the VecDeque and check its index.
While debug_validate_bug_on is still used, it does not need to be
imported directly, as that macro is marked with `macro_export`, making
it globally available to the crate.
Ticket: 7980
Usage of Vec<u8> instead of Box<u8> gave the ability to callers
to grow the buffer (indefinitely)
This was regressed in 16fee33368
Additionnaly, use rust WriteZero instead of WouldBlock as a more
fitting error when cursor is full, as that error kind is the
one tested by callers.
Realloc alp_ctx.ctxs when a dynamic alproto is registered and
g_alproto_max increases. So dynamic alproto can be treated as
real/normal ones. And app-layer switch can be set to any value
of no/deteciton-only/yes.
Ticket: 8000