------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1403 Todd Lyons <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #7 from Todd Lyons <[email protected]> 2013-10-25 16:44:54 --- Viktor pointed out that merely changing the regex fixed the issue for him. When he changed his regex to (.*) instead of (.)*, his pcre library didn't fail (because the stack utilization to track potential matches dropped way down). I can reliably repeat that success with the changed regex with 10000 items: $ perl -e '$items=10000; $count=1; print "x\@test.ex: "; while($count < $items){print "test$count.ex,"; $count++;}; print "test$count.ex\n";' > /tmp/forwardtable $ ../src/build-Linux-i386/exim -be '${if match{${lookup{[email protected]} lsearch*@{/tmp/forwardtable}}}{^(.*)@(.*)\$} {true}{false}}' false I tested up to 100000 items, which worked as expected. The final verdict as Viktor pointed out, this is a case where adjusting the regex design fixes the problem. And the bad regex design isn't an exploitable case. I'll leave this open in order to work on adjusting the regex call. pcre_exec(), if called with a match limit, can return PCRE_ERROR_RECURSIONLIMIT if it hits that limit. Then we can more elegantly detect and set an error string that the regex had a problem and fail the match. -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
