Project

General

Profile

Actions
Copy link

Bug #2917

open

Unable to find the sm in any of the sm lists

Added by Peter Manev almost 4 years ago. Updated over 2 years ago.

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

Description

How to reproduce - enable all rules in an ETPro ruleset and load them.

suricata -T -S "rules/*.rules" 

[36522] 3/4/2019 -- 04:02:13 - (suricata.c:1851) <Info> (ParseCommandLine) -- Running suricata under test mode
[36522] 3/4/2019 -- 04:02:13 - (suricata.c:1064) <Notice> (LogVersion) -- This is Suricata version 5.0.0-dev (rev 7f0bdc662)
[36522] 3/4/2019 -- 04:03:04 - (detect-parse.c:576) <Error> (SigMatchListSMBelongsTo) -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - Unable to find the sm in any of the sm lists
[36522] 3/4/2019 -- 04:03:04 - (suricata.c:2971) <Notice> (main) -- Configuration provided was successfully loaded. Exiting.
Actions
Copy link
 #1

Updated by Victor Julien almost 4 years ago

can you pin point a specific rule?

Actions
Copy link
 #2

Updated by Andreas Herz over 3 years ago

  • Assignee set to OISF Dev
  • Target version set to TBD
Actions
Copy link
 #3

Updated by Andreas Herz over 3 years ago

  • Status changed from New to Feedback
Actions
Copy link
 #4

Updated by Victor Julien over 3 years ago

I'm not seeing this with current rules. @Peter Manev do you still have the set to reproduce this?

Actions
Copy link
 #5

Updated by Peter Manev over 3 years ago

I dont see it anymore with the 5.0 ruleset.

Actions
Copy link
 #6

Updated by Andreas Herz over 3 years ago

  • Status changed from Feedback to Closed
Actions
Copy link
 #7

Updated by Peter Manev almost 3 years ago

Tested with - Suricata version 6.0.0-dev (0c5c2173b 2020-03-14)

Thanks to Brandon M (PFPT) it is now possible to narrow down and reproduce the issue.

alert http $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TEST 1"; flow:to_server,established; content:"GET"; http_method; flowbits:set,test; sid:1;)

# does not work - based on the original rules
alert http $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"TEST 2"; flowbits:isset,test; pcre:"/\s200\s/"; sid:2;)

# works - removing the flowbit
#alert http $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"TEST 2"; pcre:"/\s200\s/"; sid:2;)

# works - sub pcre with content - this validates it something with the flowbit relationship? 
#alert http $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"TEST 2"; flowbits:isset,test; content:"|20|200|20|"; sid:2;)

# works - add a buffer to the pcre
#alert http $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg:"TEST 2"; flowbits:isset,test; pcre:"/200/S"; sid:2;)

It seems "Unable to find the sm in any of the sm lists" gets triggered specifically by a combination of flowbits plus non buffered pcre ...
The rules above are definitely not optimal - they just depict the issue and make it reproducible.

Actions
Copy link
 #8

Updated by Peter Manev almost 3 years ago

  • Status changed from Closed to New

(re-opening)

Actions
Copy link
 #9

Updated by Jeff Barber over 2 years ago

An additional way of reproducing this in the released 6.0.0 version is this rule:

alert dns any any -> any any (msg:"VU#257161:CVE-2020-11901 DNS malformed response to provide incorrect size for heap allocation error"; isdataat:129 ; app-layer-event:dns.malformed_data; sid:1371257161; rev:1;)

That was my attempt to adapt a snort rule from https://github.com/CERTCC/PoC-Exploits/blob/master/vu-257161/vu-257161.rules, which uses a suricata-rejected pairing of app-layer-event and dsize (following the suggestion at https://suricata.readthedocs.io/en/suricata-6.0.0/rules/differences-from-snort.html#don-t-cross-the-streams).

alert dns any any -> any any (msg:"VU#257161:CVE-2020-11901 DNS malformed response to provide incorrect size for heap allocation error"; dsize:>128 ; app-layer-event:dns.malformed_data; sid:1371257161; rev:1;)
Actions
Copy link

Also available in: Atom PDF