"s" flag - PCRE_DOTALL If this bit is set, a dot metacharacter in the pattern matches a char- acter of any value, including one that indicates a newline. However, it only ever matches one character, even if newlines are coded as CRLF. Without this option, a dot does not match when the current position is at a newline. This option is equivalent to Perl's /s option, and it can be changed within a pattern by a (?s) option setting. A negative class such as [^a] always matches newline characters, independent of the set- ting of this option.
"i" flag - PCRE_CASELESS If this bit is set, letters in the pattern match both upper and lower case letters. It is equivalent to Perl's /i option, and it can be changed within a pattern by a (?i) option setting. In UTF-8 mode, PCRE always understands the concept of case for characters whose values are less than 128, so caseless matching is always possible. For characters with higher values, the concept of case is supported if PCRE is com- piled with Unicode property support, but not otherwise. If you want to use caseless matching for characters 128 and above, you must ensure that PCRE is compiled with Unicode property support as well as with UTF-8 support.
Lead Security Researcher, SpiderLabs
Trustwave | SMART SECURITY ON DEMAND
How is it possible that suricata and mod_security use different values to evaluate insensitive expressions?
Within mod_security equivalent pcre for insensitive should be (as we can see on rx directive): "@rx (?i)nikto"
while in suricata should be /nikto/i
So if both are using pcre software and libraries, how is it possible that insensitive searchs perform in different way for each software?
If I want to parse a pcre to match a vulnerability, not exploit, should I parse all the pcre into normal content and finally convert it again into pcre for mod_security?
Which pcre does modsecurity uses? Is there any manual reference?
2014-01-29 Jose Pablo Valcárcel Lázaro <firstname.lastname@example.org>
I was wondering if someone could advice me how to convert regular expression as/<OBJECT\s+[^>]*classid\s*=\s*[\x22\x27]?\s*clsid\s*\x3a\s*\x7B?\s*E2883E8F-472F-4fb0-9522-AC9BF37916A7.+offer-(ineligible|preinstalled|declined|accepted)/si
into mod_security compatible regular expression.
Looking at the exploit exploit vulnerability string is
So I understand that using the pcre you should be able to stop any variation of the exploit?