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.
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.
Arne Welzel [Wed, 29 Mar 2023 15:29:31 +0000 (17:29 +0200)]
af-packet: Ignore outgoing packets on loopback interfaces
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.
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 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:
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.
Jason Ish [Mon, 1 May 2023 16:50:40 +0000 (10:50 -0600)]
detect: fix setting of flag for rule reload
As part of 6d8b50b748844e9de6010cde5a6b139148c0e937, 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.
policy: postpone evaluation of exception policy after setting the engine mode
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.
Lukas Sismis [Fri, 31 Mar 2023 12:31:59 +0000 (14:31 +0200)]
bpf: refactor the BPF code and postpone querying of the engine mode
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.
projects / thirdparty / suricata.git / log
