Ticket: 8537
Otherwise, it may cause a use-after-free, in case of reallocated
buffer and we used the buffer inspect which was freed.
(cherry picked from commit 6d437956e2)
Ticket: 8536
Otherwise, it may cause a use-after-free.
So, need to allocate the temporary vector, before calling
SCInspectionBufferCheckAndExpand
(cherry picked from commit 2b20a436e7)
Ticket: 8513
Suricata decides at 2 levels if a http2 flow is doing a compression
bomb.
There is a direct computation when one chunk of TCP data
is being parsed.
In this case, do not take the ratio into account, just use the size
of the decompressed data, so that if we get a big chunk of TCP data
like 1 MiB, and a not so high ratio of 200, we do not trigger
the debug assertion in util-file.c about 64MiB
The other case stays unchanged : when accumulating over the lifetile of
a flow with multiple txs, take into account the compression ratio,
so that a flow of many txs, having a super high (brotli) compression
ratio, ends up classified as a compression bomb.
(For example, having 100 txs each turning a 100 byte input into a 700 KiB
one)
(cherry picked from commit bf64b52b95)
Ticket: 8529
When Suricata handles a HTTP1 response body, it does so with a
file, and tries to get the filename from the Content-Disposition
header if any, then from the uri.
If it failed to find a file name, it tried again every time
there was new data from the response body, even if there was
no new data to find a file name in either the header nor the uri.
This causes a slowdown in the case the Content-Disposition header
is big.
Fix is to set the flag on the first call of the callback, to be
sure that we will parse the Content-Disposition header for a
filename header only once per http1 response.
(cherry picked from commit 9aaa6f7854)
Ticket: 8513
During decompression, fail early if we have a big decompression
ratio, and enough data.
Track this data also during a tx lifetime, and even a flow/state
lifetime, so that we set event and fail also if the compression
bomb is split over multiple packets
(cherry picked from commit 7bf48b02be)
Decoding the reassembled packet inside DefragInsertFrag while holding
the tracker mutex creates a deadlock situation if the reassembled packet
contains tunneled fragments: two threads could each hold one tracker
mutex and deadlock on the other. Move the decode in Defrag() after
DefragTrackerRelease() so no lock is held during decode (and possibly
re-entering the defrag system).
Make sure to fetch tracker->ip_hdr_offset after DefragInsertFrag since
it may be written during that call if the first fragment arrives last.
Issue: 8550
(cherry picked from commit 1dc629d978)
So that we can write a final zero without overflowing the array
and relying on padding to avoid further problems
Ticket: 8448
(cherry picked from commit 38d41e6fa6)
Ticket: 8526
As some C protocols accepted case-insensitive frame names,
a rule using the same frame twice with different cases,
ended up using 2 different buffers,
which ended up in triggering a buffer overflow
(cherry picked from commit c977b2f31b)
Ticket: 8510
Without this check, in case of a hash collision, and the other
fields are equal, we could end up consider adding an IPv6 packet
to a IPv4 tracker (or vice versa).
Doing so, we end up interpreting an IPv6 packet as an IPv4 one,
and we do not benefit from the bounds checks from ipv4/ipv6 decoder.
(cherry picked from commit 24527d662a)
Ticket: #8394
Backport note: main-8.0.x does not have the keyword information flag
constants from main, so keep SIGMATCH_SUPPORT_FIREWALL and omit the
informational SIGMATCH_INFO_* flags.
(cherry picked from commit fd31e50954)
Store the NTP reference ID as raw network-order bytes so it can be
exposed as a sticky buffer and matched with payload keywords. The
reference ID is often a 4 character string, or an IP address and not
just an integer identifier.
Updates the log reference ID to be a string of colon separated hex
digits as this matches what tshark does.
Ticket: #8488
(cherry picked from commit 713e4eb900)
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.
(cherry picked from commit 879846e153)
Adds basic NTP transaction logging for the current supported message
types.
Includes small cleanups around reference ID.
Ticket: #8425
(cherry picked from commit 31b967b089)
Ticket: 8336
At the end of a TLS handshake, in IDS mode, the client acks,
and we parse the server hello and use tls.encryption-handling
to know what to do next (for example bypass)
Everything is parsed, but we have not run detection yet on neither
side.
So, in IDS mode, we need to first flush the client side, as the
comment on the function already stated.
(cherry picked from commit cefd134461)
Ticket: 8336
When a packet has flag PKT_PSEUDO_DETECTLOG_FLUSH, we do not
expect to rerun detection on the same tx and direction again
So, do not set mpm_in_progress whose purpose is to not store
the state as we will run again.
Allows transactional bidirectional signatures to work on
thse log+flush pair of packets
(cherry picked from commit 1ba411458c)
When an alert is generated from firewall context, add an engine value of
"fw", otherwise "td" (for threat detect).
The engine field is only added when firewall mode is enabled.
Ticket: #8456
(cherry picked from commit 029fd1be59)
The first version of the event set done=true on state->curr_tx and
returned NULL when the limit hit. curr_tx is usually the active
command just received — marking it done mid-request throws off
response matching, and subsequent commands in the flow stop getting
logged.
SMB behavior is mirrored here:
Walk the tx list, find the oldest tx that isn't done, mark
it done and tag it with the event, then fall through and
create the new tx so the flow parsing continues. One stale tx gets
reaped per overflow so memory stays bounded.
Issue: 8489
(cherry picked from commit 5ddd808e9b)
Other parsers (SMB, POP3, ENIP) already raise a too_many_transactions
event when a flow exceeds its per-flow transaction limit. FTP had
the limit wired up through app-layer.protocols.ftp.max-tx but just
dropped the excess transaction on the floor with a "FTP does not set
events yet..." TODO, so no event was raised when the limit was
reached.
Add the FtpEventTooManyTransactions variant, a stock rule at
sid 2232002, and raise the event from FTPTransactionCreate when the
live-tx count goes past ftp_config_maxtx.
Issue: 8489
(cherry picked from commit 9ea2e29581)
When we got a bind without the first fragment flag, and did not
set any_frag in the signature, the signature always matched,
whatever the uuid value
Ticket: 8457
(cherry picked from commit e38888810d)
Shivani Bhardwaj
Philippe Antoine
Jeff Lucovsky
Jason Ish
Victor Julien
Sergey Pinaev
alinse-pltzr
Jeff Lucovsky