Use of potentially dangerous function: localtime
Windows localtime is thread safe and no localtime_r is availabe on
Windows, so use separate logic for Windows.
Remove the global "run_mode" var as it was a duplicate of the runmode on
the "instance" struct. For direct access outside of suricata.c, use the
getter function.
Also expose a setter function for unit tests that need to change it.
Since there is code in place that skips over invalid base64 characters
and creates a new array out of the remainder vector, all test must be
made after that final array has been created and against the variable
that holds the actual length of the final array.
Also, don't treat a successful decoding that had invalid characters as
errors. The caller does not treat them as errors so it makes sense to
consider it successful if something was decoded.
Bug 6964
Base64 decoder tried to handle several different cases in one fn
including how the data should be decoded and corresponding consumed and
decoded bytes calculated for RFC 2045 and RFC 4648 which are very
different. This left window for mistakes and edge cases that one mode is
not supposed to take care of while the other can.
Separate the decoder per RFC so as to have each variable their own scope
and playground. This also makes it much easier to debug if there are any
issues in decoding w.r.t. different callers.
This also takes care of some known issues like making sure the consumed
bytes are correctly handled.
Bug 6964
This implements a logger for the SDP protocol.
Given that SDP is encapsulated within other protocols (such as SIP),
enabling it separately is not necessary.
Ticket #6627
This implements a parser for the SDP protocol.
Given that SDP is encapsulated within other protocols (such as SIP),
enabling it separately is not necessary.
Ticket #6627.
Ticket: 6889
To avoid regexp dos with too much backtracking.
This is already done on pcre keyword, and pcrexform transform.
We use the same default limits for rules parsing.
Ticket: 6892
As HTTP hpack header compression allows one single byte to
express a previously seen arbitrary-size header block (name+value)
we should avoid to copy the vectors data, but just point
to the same data, while reamining memory safe, even in the case
of later headers eviction from the dybnamic table.
Rust std solution is Rc, and the use of clone, so long as the
data is accessed by only one thread.
The list of fragments may still contain overlaps, so adding up the
fragment lengths is flawed. Instead track the largest size of
contiguous data that can be re-assembled.
Bug: #6675
Fix the BSD policy case where a subsequent fragment starts before an
original fragment and overlaps the beginning of the original
fragment. In this case the overlapping data from the new fragment is
preferred.
Suricata was preferring the data from the original fragment, but it
should only do that when the original fragment has an offset <= to the
new fragment.
- Adds tests for this case.
Bug: #6669
Instead of breaking the loop when the current fragment does not have
any more fragments, set a flag and continue to the next fragment as
the next fragment may have data that occurs before this fragment, but
overlaps it.
Then break if the next fragment does not overlap the previous.
Bug: #6668
When we only have stream matches.
Ticket: 6846
This solves the case where another transaction was created
by parsing data in the other direction, before running the
detection.
Like
1. get data in direction 1
2. acked data: parse it, but do not run detection in dir 1
3. other data in direction 2
4. other data acked : parse it and create new tx,
then run detection for direction 1 with data from first packet
Unsafe handling of buffer offset and to be inserted data's length
could lead to a integer overflow. This in turn would skip growing
the target buffer, which then would be memcpy'd into, leading to
an out of bounds write.
This issue shouldn't be reachable through any of the consumers of
the API, but to be sure some debug validation checks have been
added.
Bug: #6903.
For the capture methods that support livedev and IPS,
livedev.use-for-tracking is not supported.
This setting causes major flow tracking issues, as both sides of
a flow would be tracked in different flows.
This patch disables the livedev.use-for-tracking setting if it
is set to true. A warning will be issued.
Ticket: #6726.
When we added feature #5976 (72146b969), we overlook that we also have
a config stats option for the human-readable stats logs to output
0 counters.
Due to not seeing this before, we now have two different setting names
for basically the same thing, but in different logs:
- zero-valued-counters for EVE
- null-values for stats.log
This ensures we use the same terminology, and change the recently added
one to `null-values`, as this one has been around for longer.
Task #6962
The stats config for EVE logs have a comment about exception policy
stats counters. This went in with 72146b969c, but shouldn't have,
as there are no options there.
Issue: 6864
Multiple IP options were not handled properly as the value being OR'd
into the packet's ip option variable were enum values instead of bit
values.
Victor Julien
Jason Ish
Shivani Bhardwaj
Giuseppe Longo
Philippe Antoine
Lukas Sismis
Juliana Fajardini
Jeff Lucovsky