Bug #1926
openFeature #4855: rules: refactor rule parsing into multi-stage parser
rule parsing: wrong content checked for fast_pattern (snort compatibility)
Description
Given a rule like:
content:"AAAA"; fast_pattern:only; content:"BBBB"; http_raw_uri; content:"AAAA"; distance:0; http_raw_uri;
The distance will end up checking the the first occurrence of content for "fast_pattern:only" instead of the previous content, as its not looking for the previous content on the http_raw_uri list.
If the rule is modified to have the distance after http_raw_uri, eg:
content:"AAAA"; fast_pattern:only; content:"BBBB"; http_raw_uri; content:"AAAA"; http_raw_uri; distance:0;
then the correct contents is checked as the rule parsing context is on the correct list.
However, from the rule writers perspective these 2 variations should result in the same outcome.
Updated by Victor Julien about 6 years ago
- Assignee changed from Jason Ish to Victor Julien
Updated by Victor Julien about 6 years ago
- Target version changed from 70 to TBD
It seems that to properly fix this we'd need a 2 stage rule parser. In this case distance already connects the 2 contents before the 2nd one is considered to be http_raw_uri.
Updated by Victor Julien about 6 years ago
- Related to Bug #1826: Rule validation bug with fast_pattern:only and specified buffers added
Updated by Victor Julien about 5 years ago
- Related to Bug #2205: Buffer confusion with fast_pattern:only; added
Updated by Victor Julien about 5 years ago
- Related to Feature #3317: rules: use rust for tokenizing rules added
Updated by Victor Julien almost 3 years ago
- Status changed from Assigned to New
- Assignee changed from Victor Julien to OISF Dev
- Target version changed from TBD to 8.0.0-beta1