------- 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 <tlyons@???> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #7 from Todd Lyons <tlyons@???> 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{x@???}
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
