Bug #2917
openUnable to find the sm in any of the sm lists
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.
Updated by Andreas Herz over 3 years ago
- Assignee set to OISF Dev
- Target version set to TBD
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?
Updated by Peter Manev over 3 years ago
I dont see it anymore with the 5.0 ruleset.
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.
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;)