Re: Changes to PCRE

[Steven Sturges <steve.sturges () sourcefire com>]

Hi Ed--

There are two limits within Snort to keep PCRE under control and prevent 
a poorly written PCRE from causing issues when processing a
packet that 1) could take too much time causing drops, and 2) causing
a stack explosion causing a segfault.

Namely, Snort limits the calls to PCRE's internal 'match' function in
two ways -- one limit is the amount of back tracking and the other
limit is the number of times it can be called recursively.

See the big table of Snort config items in section 2.1.3 of
the Snort manual for details -- reference pcre_match_limit and
pcre_match_limit_recursion configurations.  Reference the PCRE
documentation for better descriptions of how these may apply to
certain expressions and data blocks.

Also, as a side note, these were added back in Snort 2.8.1 -- circa
2008.  Not sure what version of Snort the papers were referencing, but
certainly the 2006 one would have been prior to that Snort being
released.  :)

Cheers.
-steve

On 7/11/13 9:49 AM, Phelps Ed (Ed) ** % ** wrote:
> Hello All,
>
> I’ve spent a good chunk of time in recent months reading papers and
> trying to “break” snort. In particular, two papers from 2006
> (http://www.acsac.org/2006/papers/54.pdf) and 2010
> (http://ieeexplore.ieee.org/xpls/abs_all.jsp?arnumber=5462149&tag=1)
> have kind of been my guiding literary forces. From a high-level, these
> papers focus on “evil” regular expressions and the time that it takes
> for snort to process them, forcing dropped packets when snort cannot
> keep up.
>
> When I attempt similar techniques on more modern versions of snort
> (2.9.2.2 – 2.9.5), I cannot replicate their results as snort barely bats
> an eye to the crafted packets. Even when I implement rules with regular
> expressions that no sane snort owner would even consider implementing
> (pcre:“/(a+a+)+b/” or pcre:”/(.)*(a)(.)*=(.)*b\2 /”) and packets that I
> know should create an exponential search time, snort makes the correct
> alert/allow decision in every instance with no delays. Surely this is a
> testament to snort developers and the community making the necessary
> changes in a timely manner to avoid dropped packets.
>
> So what changed? I can’t seem to find any documentation on changes made
> to solve the “evil regex” problem, but it seems to be very efficiently
> solved. I was hoping someone could point me in the right direction,
> whether it is an algorithm tweak, a change from NFAs to DFAs, or
> something I haven’t thought of (the most likely answer).
>
> Thanks,
>
> Ed
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
>
>
> _______________________________________________
> Snort-devel mailing list
> Snort-devel () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
> Archive:
> http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel
>
> Please visit http://blog.snort.org for the latest news about Snort!

------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!