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.