Bug #1960: Error while parsing rule with PCRE keyword with semicolon - Suricata - Open Information Security Foundation

Actions

#1

Updated by Andreas Moe over 7 years ago

I see, that this also occures when having a semicolon in the "msg" field, and a "content" field. As far as documentation i have come across (both with regard to PCRE and Suricata) ";" is not a special character that should need to be escaped. Correct me if i'm wrong.

Actions

Copy link

#2

Updated by Jason Ish over 7 years ago

Assignee set to Jason Ish

First note that your rule is missing a ';' between the pcre option and sid.

Anyways, I think this is a documentation issue. Semi-colons must be escaped in msg and content like they do in Snort, and it looks like this applies to pcre's as well. I'll try to come up with something generic in the documentation, and then explictly mention it in the msg, content and pcre options like it is done in the Snort manual.

Actions

Copy link

#3

Updated by Andreas Moe over 7 years ago

Ah, yes missed that missing semicolon, the provided rule was just to quickly test / provide documentation for a previously encountered scenario. When running the same rule with a semicolon after the PCRE, it gives the same error.

23/11/2016 -- 21:43:14 - <Info> - Running suricata under test mode
23/11/2016 -- 21:43:14 - <Notice> - This is Suricata version 3.2RC1 RELEASE
23/11/2016 -- 21:43:14 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - bad option value formatting (possible missing semicolon) for keyword pcre: '"/value:[0-9]+'
23/11/2016 -- 21:43:14 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - error parsing signature "alert ip any any -> any any (msg:"semicolon in pcre"; content:"value:"; pcre:"/value:[0-9]+; test/"; sid:1; rev:1;)" from file /usr/local/etc/suricata/rules/moe.rules at line 1

Would it not be possible to check if this semicolon is confined to within quotes for a keyword and or within a PCRE? Seems that there is something wihtin the splitting of keywords and parsing of the signature that prematurely splits the signature into different "tokens" / substrings.

I haven't tested, but does this f.ex also affect other keywords that contain quouted strings: "replace", "filename", "fileext", "filemagic", "tls.subject", "tls.issuerdn". And possibly more.

Actions

Copy link

#4

Updated by Jason Ish over 7 years ago

Andreas Moe wrote:

Ah, yes missed that missing semicolon, the provided rule was just to quickly test / provide documentation for a previously encountered scenario. When running the same rule with a semicolon after the PCRE, it gives the same error.

[...]

Would it not be possible to check if this semicolon is confined to within quotes for a keyword and or within a PCRE? Seems that there is something wihtin the splitting of keywords and parsing of the signature that prematurely splits the signature into different "tokens" / substrings.

I haven't tested, but does this f.ex also affect other keywords that contain quouted strings: "replace", "filename", "fileext", "filemagic", "tls.subject", "tls.issuerdn". And possibly more.

This will affect all those options. Honestly I'm not sure if we could handle this case without breaking all the rules out there that already do proper escaping.

Actions

Copy link

#5