Bug #6894
openbsize validation FP on content negation with hex encoded 0d 0a
Description
consider the following rule, which contains
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TEST"; flow:established,to_server; http.header_names; bsize:10; content:!"|0d 0a|User-Agent|0d 0a|"; content:"|0d 0a|Host|0d 0a 0d 0a|"; sid:1;)
[129 - Suricata-Main] 2024-03-24 22:40:11 Error: detect-bsize: signature can't match as required content length 14 exceeds bsize value: 10 [129 - Suricata-Main] 2024-03-24 22:40:11 Error: detect: error parsing signature "alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"TEST"; flow:established,to_server; http.header_names; bsize:10; content:!"|0d 0a|User-Agent|0d 0a|"; content:"|0d 0a|Host|0d 0a 0d 0a|"; sid:1;)" from file /tmp/49c7c31b54ecbe71_Mar-24-2024_22-40-11/dalton-custom.rules at line 1
I've been able to isolate the issue to the hex encoded values within the content negation.
if you remove one of the |0d 0a|
within content:!"|0d 0a|User-Agent|0d 0a|";
the error produced reports a required length of 12.
Updated by Victor Julien 7 months ago
I agree the error message needs to be fixed for this negation case.
But what is the point of having a negated match that can't possibly fit the bsize
budget? We can know content:!"|0d 0a|User-Agent|0d 0a|";
will be true at parsing time, right? I guess I'm saying that I do think the rule should at least warn you that there is a useless combination of expressions.
Updated by Brandon Murphy 7 months ago
Victor Julien wrote in #note-1:
But what is the point of having a negated match that can't possibly fit the
bsize
budget?
This is a great question.
I'm curious though, is there an order of operations that could impact the performance profile of such a rule?
We can know
content:!"|0d 0a|User-Agent|0d 0a|";
will be true at parsing time, right?
In this example, yes, but this is also just a simple example. I'm not sure this exact example occurs in the ET ruleset, but i'm SURE the condition you're speaking about does.
I'm guessing these conditions (where the negation can't possibly be present given the bsize limitation) are likely "artifacts" created by the process of updating rules logic that checked for header order (largely by pcre) from http_header to http.header_names. In the old buffers, these negations made a lot of sense in the old style of rules.
I guess I'm saying that I do think the rule should at least warn you that there is a useless combination of expressions.
I agree, it'd be great! is that a separate feature request? It'd help me a lot in identifying all the rules that have this condition, in the various buffers, to get them cleaned up
Updated by Brandon Murphy 7 months ago
Brandon Murphy wrote in #note-2:
I'm curious though, is there an order of operations that could impact the performance profile of such a rule?
This is an example of one where this question is relevant:
http.header_names; bsize:22; content:"|0d 0a|Host|0d 0a|Connection|0d 0a 0d 0a|"; content:!"User-Agent"; content:!"Referer";
While I'm sure the answer is "it depends" and currently is likely impacted by #4226, are the negations helping the engine in any way in the above example? or is it better to remove the negations and let the bsize and content handle all the required optimization?
Updated by Jeff Lucovsky 7 months ago
- Related to Feature #4226: bsize: apply as depth to patterns added
Updated by Jeff Lucovsky 6 months ago
- Subject changed from bsize valdation FP on content negation with hex encoded 0d 0a to bsize validation FP on content negation with hex encoded 0d 0a