Bug #12956


suricata fails to use pcre in SID management (e.g. dropsid.conf)

Added by Adam CM 3 months ago. Updated 3 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
Plus Target Version:
Affected Version:
Affected Plus Version:
Affected Architecture:


In suricata/, under "Test the SID token for the PCRE: keyword", the match for the regular expression will be quoted as follows:

$regex = '/' . preg_quote($matches[2], '/') . '/i';

This defeats the purpose of having the "pcre:" tag in the first place as this means that only the literal string will be matched. If it worked at all previously, this is a major regression for things like dropsid.conf because once-working drop rules will be no longer drop rules.

Actions #1

Updated by Adam CM 3 months ago

Actions #2

Updated by Marcos Mendoza 3 months ago

  • Status changed from New to Closed
  • Priority changed from Very High to Normal

The commit says it resolves issue #10244. The reasoning given there is:

The chosen solution was to mimic the current Snort behavior by calling preg_quote() with the user-supplied pcre search string to insure any embedded '/' characters are properly escaped. The comments in the SID MGM configuration file examples state that when using the "pcre" keyword that inclusion of the '/' delimiters is NOT required.

I understand that to mean that pcre can still be used, but the pattern delimiters do not need to be included. If there is one, details showing the issue should be provided. It's probably best to take this to the forums at this point. Given these reasons, I am closing this for now.

Actions #3

Updated by Marcos Mendoza 3 months ago

  • Status changed from Closed to Confirmed

I'm reopening this issue, as the function preg_quote escapes all special characters, rather than just delimiters.

Indeed, this patch does make pcre significantly less effective, and it doesn't seem worth it for the benefit of input validation.


Also available in: Atom PDF