Closed vorner closed 3 years ago
The commit reference above fixes this issue, it was in the quote stripping. However, as discussed in #176, not stripping the quotes at all fixes this issue. However, a function to strip quotes would still be a useful utility method, so will fix this.
Hello
Thanks for the super-fast fix. But as I'm looking at the code, it seems ;
is also special and should eat the backslash in front of it:
https://suricata.readthedocs.io/en/suricata-6.0.0/rules/intro.html#rule-options
Hopefully, that's all of them.
Thanks for the super-fast fix. But as I'm looking at the code, it seems
;
is also special and should eat the backslash in front of it:
This should already happen in parse_option
and has a test here: https://github.com/jasonish/evebox/blob/master/suricata-rule-parser/src/lib.rs#L408
Closing. Fixed with 0b63979d27adc3102919532b6e3d44baa52f2578.
Hello
It seems the rust parser and suricata behaves differently when presented with backslashes in rule option values that are not escaped. Suricata seems to preserve them, while the evebox-suricata-rule-parser strips them.
This often leads to damaging
pcre
options, as they often contain backslashes that are significant for the regex itself. One that's in the example in the documentation: https://suricata.readthedocs.io/en/suricata-6.0.0/rules/payload-keywords.html?highlight=pcre#pcre-perl-compatible-regular-expressions:pcre: "/^/index\.html/$/U"
. Apparently, the\.
is meant to match literal dot and not any character.This is how it gets parsed: