Always make sure, that smd is not NULL, as we dereference it a few
lines below and base64_data for instance is forbidden as a fast_pattern
Ticket: 8504
If a runmode is missing but other params are passed on the commandline,
issue an error.
Ticket: #5711
Signed-off-by: Promise Charles <descencybobby@gmail.com>
Support scan-build's taint filtering logic. Adds a yaml config to mark
a dedicated debug validation function as filtering a taint.
Use to suppress warnings in reference, threshold and classification file
handling.
Ticket: #3153.
detect-engine.c:2350:69: warning: Out of bound access to memory after the end of 'new_det_ctx' [security.ArrayBound]
2350 | FlowWorkerReplaceDetectCtx(SC_ATOMIC_GET(s->slot_data), new_det_ctx[i]);
| ^~~~~~~~~~~~~~
1 warning generated.
suricata.c:574:5: warning: Potential out of bound access to the heap area with tainted index [security.ArrayBound]
574 | bpf_filter[nm] = '\0';
| ^~~~~~~~~~~~~~
1 warning generated.
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)
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.
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
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