Project

General

Profile

Actions

Feature #5784

closed
PA VJ

detect: allow cross buffer inspection on multi-buffer matches

Feature #5784: detect: allow cross buffer inspection on multi-buffer matches

Added by Philippe Antoine about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Effort:
Difficulty:
Label:

Description

Cf calls to InspectionBufferSetupMulti to have the keywords which use multibuffer

If I have the rules

alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicX"; mqtt.subscribe.topic; content:"topicY"; sid:5;)
alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicY"; sid:6;)
alert mqtt any any -> any any (msg:"HTTP2 - Two Headers - Authority/Method"; mqtt.subscribe.topic; content:"topicX"; sid:7;)

And run them on S-V test mqtt-sub-rules/mqtt5_sub_userpass.pcap

I get alerts for sid 6 and 7 on the same packet and transaction, but not for sid 5

In this pcap, there is a MQTT subscribe for these two different topics : topicX and topicY
But there is no topic which contain both content topicX and topicY at the same time

There is no such feature in the detection engine to have "multiple buffer" keywords have different contents for different buffers (and still have the ability to have multiple content for only one buffer)
The different contents for a unique sm_list (value can be g_http2_header_buffer_id) are aggregated in a single SigMatchData linked list

Victor, assigning to you as this requires deep design


Related issues 2 (0 open2 closed)

Related to Suricata - Bug #5780: HTTP/2 - FN when matching on multiple http2.header contentsClosedPhilippe AntoineActions
Related to Suricata - Documentation #6032: detect: document new multi-instance logicClosedJason TaylorActions

PA Updated by Philippe Antoine about 3 years ago Actions #1

  • Related to Bug #5780: HTTP/2 - FN when matching on multiple http2.header contents added

VJ Updated by Victor Julien about 3 years ago Actions #2

I think the fundamental issue is that when parsing a rule, the following statements are considered identical by Suricata:

dns.query; content:"abc"; content:"xyz";
dns.query; content:"abc"; dns.query; content:"xyz";

This leads to a "detection list" with 2 matches. The sig only matches if both match in the same buffer. Each DNS query is its own buffer, even if multiple queries are part of a single packet.

The expectation of rule writers seems to be that if the dns.query keyword is used multiple times, it "breaks" the list into 2. If a packet has a query containing "abc" and another query containing "xyz", the sig should match.

This same concept applies to all detection using the same "multi inspect buffer" logic, like certain http/2 keywords, mqtt keywords, etc.

VJ Updated by Victor Julien about 3 years ago Actions #3

  • Subject changed from Have multi buffer be able to match on different content for different InspectionBuffer to detect: allow cross buffer inspection on multi-buffer matches

VJ Updated by Victor Julien about 3 years ago Actions #4

  • Status changed from New to In Progress
  • Target version changed from TBD to 7.0.0-rc2

I'm looking into this, but it seems the changes will be too intrusive and high risk for backporting. We'll have to make the final call when this work is done for master.

PA Updated by Philippe Antoine about 3 years ago Actions #5

Victor Julien wrote in #note-2:

I think the fundamental issue is that when parsing a rule, the following statements are considered identical by Suricata:

I agree :-)

This leads to a "detection list" with 2 matches. The sig only matches if both match in the same buffer. Each DNS query is its own buffer, even if multiple queries are part of a single packet.

The expectation of rule writers seems to be that if the dns.query keyword is used multiple times, it "breaks" the list into 2. If a packet has a query containing "abc" and another query containing "xyz", the sig should match.

This same concept applies to all detection using the same "multi inspect buffer" logic, like certain http/2 keywords, mqtt keywords, etc.

Thanks for taking on this :-)

Good to see a new feature for a more expressive signature language ;-)

VJ Updated by Victor Julien almost 3 years ago Actions #6

  • Status changed from In Progress to In Review

VJ Updated by Victor Julien almost 3 years ago Actions #7

  • Status changed from In Review to Closed

PA Updated by Philippe Antoine almost 3 years ago Actions #8

Still needs to be documented, right ?
cc @Juliana Fajardini Reichow

VJ Updated by Victor Julien almost 3 years ago Actions #9

Yes, see #6032

VJ Updated by Victor Julien almost 3 years ago Actions #10

Actions

Also available in: PDF Atom