Project

General

Profile

Actions

Bug #1960

closed

Error while parsing rule with PCRE keyword with semicolon

Added by Andreas Moe about 8 years ago. Updated almost 8 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Target version:
Affected Versions:
Effort:
Difficulty:
Label:

Description

When a signature contains a semicolon ";" inside a PCRE keyword match, an error occures.

alert ip any any -> any any (msg:"semicolon in pcre"; content:"value:"; pcre:"/value:[0-9]+; test/" sid:1; rev:1;)
23/11/2016 -- 18:46:06 - <Info> - Running suricata under test mode
23/11/2016 -- 18:46:06 - <Notice> - This is Suricata version 3.2RC1 RELEASE
23/11/2016 -- 18:46:06 - <Error> - [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] - bad option value formatting (possible missing semicolon) for keyword pcre: '"/value:[0-9]+'
23/11/2016 -- 18:46:06 - <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
Actions #1

Updated by Andreas Moe about 8 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 #2

Updated by Jason Ish about 8 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 #3

Updated by Andreas Moe about 8 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 #4

Updated by Jason Ish about 8 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 #5

Updated by Jason Ish almost 8 years ago

  • Status changed from New to Closed
  • Target version set to 3.2
Actions

Also available in: Atom PDF