Mismatch in handling of unescaped backslashes

[vorner]

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:

fn main() {
    const RULE: &str = r#"alert http $HOME_NET any -> $EXTERNAL_NET any (msg:""; http_uri; content:"index."; pcre: "/^/index\.html/$/U"; sid:9000000; rev:1;)"#;
    let rule = evebox_suricata_rule_parser::parse_rule(RULE).unwrap();
    dbg!(rule);
}

        RuleOption {
            key: "pcre",
            val: Some(
                "/^/index.html/$/U",
            ),
        },

[jasonish]

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.

[vorner]

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.

[jasonish]

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

[jasonish]

Closing. Fixed with 0b63979d27adc3102919532b6e3d44baa52f2578.