[Snort-devel] Changes to PCRE

Phelps Ed (Ed) ** % ** edphelps at ...3412...
Thu Jul 11 09:49:38 EDT 2013


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

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20130711/a1b5c584/attachment.html>


More information about the Snort-devel mailing list