Project

General

Profile

Actions

Bug #6894

open

bsize validation FP on content negation with hex encoded 0d 0a

Added by Brandon Murphy about 2 months ago. Updated 27 days ago.

Status:
New
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

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.


Related issues 1 (1 open0 closed)

Related to Suricata - Feature #4226: bsize: apply as depth to patternsAssignedJeff LucovskyActions
Actions #1

Updated by Victor Julien about 2 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.

Actions #2

Updated by Brandon Murphy about 2 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

Actions #3

Updated by Brandon Murphy about 2 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?

Actions #4

Updated by Jeff Lucovsky about 2 months ago

  • Related to Feature #4226: bsize: apply as depth to patterns added
Actions #5

Updated by Jeff Lucovsky 27 days 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
Actions

Also available in: Atom PDF