It was pointed out by a contributor that our workflow mentioned
rewrite-branch as the preferred way, while in fact our policy is to add
said changes to a different commit. Updating documentation to prevent
other situations like that.
Although we prefer that formatting changes (e.g. the ones made by
running clang) go in a different commit, our script error message was
still suggesting `rewrite-branch` as an option. Removed that and added
that the changes made by the script should go into a separate commit.
This flag is no longer needed as a parser can now create a transaction
as unidirectional.
Setting this flag also doesn't make sense on parsers that may have
request/reply and some unidirectional messaging.
Use a fixed type of max_pending_packets instead of intmax_t which can
differ based on the platform/standard library.
Should also prevent lints about possible arithmetic overflow.
Problem:
If we receive a long line w/o LF, we cap it to 4k bytes and wait until a
line with LF comes in order to consider the previous line complete. Any
data post the 4k bytes is discarded. Currently, if a line with LF comes
in after a long line, we reset all the parameters used for processing it
like the line.len and line.delim_len but we still make the call to
SMTPProcessRequest fn without even the need to process anything. Since
such a line (with len and delim_len set to 0) should not reach mime
decoder, a debug assertion triggers there in this case.
Fix:
Make sure to return early as the line has to be skipped and not
processed at all.
Bug 6019
When reading a loopback interface, packets are received twice: Once as
outgoing packets and once as incoming packets.
Libpcap ignores outgoing packets. With current versions of Suricata, sniffing
a single http://localhost:80 request over lo using the af-packet source
minimally shows two syn packets, two synacks and twice as many packets in
the stats entries than you'd expect when running tcpdump or Wireshark.
Multi buffer matching is implemented as a way for a rule to match
on multiple buffers within the same transaction.
Before this patch a rule like:
dns.query; content:"example"; dns.query; content:".com";
would be equivalent to:
dns.query; content:"example"; content:".com";
If a DNS query would request more than one name, e.g.:
DNS: [example.net][something.com]
Eeach would be inspected to have both patterns present. Otherwise,
it would not be a match. So the rule above would not match, as neither
example.net and somthing.com satisfy both conditions at the same time.
This patch changes this behavior. Instead of the above, each time the
sticky buffer is specified, it creates a separate detection unit. Each
buffer is a "multi buffer" sticky buffer will now be evaluated against
each "instance" of the sticky buffer.
To continue with the above example:
DNS: [example.net] <- matches 'dns.query; content:"example";'
DNS: [something.com] <- matches 'dns.query; content:".com"'
So this would now be a match.
To make sure both patterns match in a single query string, the expression
'dns.query; content:"example"; content:".com";' still works for this.
This patch doesn't yet enable the behavior for the keywords. That is
done in a follow up patch.
To be able to implement this the internal storage of parsed rules
is changed. Until this patch and array of lists was used, where the
index was the buffer id (e.g. http_uri, dns_query). Therefore there
was only one list of matches per buffer id. As a side effect this
array was always very sparsely populated as many buffers could not
be mixed.
This patch changes the internal representation. The new array is densely
packed:
dns.query; content:"1"; dns.query; bsize:1; content:"2";
[type: dns_query][list: content:"1";]
[type: dns_query][list: bsize:1; content:"2";]
The new scheme allows for multiple instances of the same buffer.
These lists are then translated into multiple inspection engines
during the final setup of the rule.
Ticket: #5784.
As part of 6d8b50b748, the settings of
THV_CAPTURE_INJECT_PKT ended up in a location unreachable by capture
methods that did not have PktAcqBreakLoop.
Instead, always call TmThreadsCaptureBreakLoop which handles the logic
for how the read loop should be broken.
This fixes the case where read threads won't "break" for rule reloads
until packets are seen.
Ticket: #6021
Querying an engine mode with an unknown value signals a bug when
the engine mode has not been determined but is already queried by
other functions.
Ticket: #5959
Master exception policy queried engine mode earlier than it was
determined from the configuration file/command line. As a result it
used the default (IDS) mode. However, the engine mode could have been
reconfigured later on to the IPS mode. This lead into an undefined behavior
as master exception policy behaves according to the configured engine mode.
Ticket: #5960
BPF codebase queried engine mode earlier than it was determined from
the configuration file/command line. As a result it used the default (IDS)
mode where it could've been configured later on to the IPS mode.
This could lead into an undefined behavior as some Suricata modules behave
according to the engine mode.
PF-Ring, Netmap and AF-Packet all shared almost identical code for
determining the engine mode. It was put into one common function.
Omitted the usage of SCStrdup function in PF-Ring module as it is
uppercased during thread initialization phase.
Ticket: #5957
sawp 0.12 is available and addresses future compilation failures in
dependent crates.
Updated modbus test case to expect 12 bytes needed instead of 15. This
aligns with expectations as the test case slices 3 bytes off the end of
a 12 byte message so needing 12 bytes is correct.
Ticket #5989
Victor Julien
Wes Hurd
Andreas Herz
Lancer Cheng
tianjinshan
Bazzan Don
Morris Chan
Juliana Fajardini
Rafael Girão
Jason Ish
John Dewey
Philippe Antoine
Philippe Antoine
Shivani Bhardwaj
Arne Welzel
Lukas Sismis
Jeff Lucovsky
William Correia