------- You are receiving this mail because: -------
You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=1403
--- Comment #3 from Todd Lyons <tlyons@???> 2013-10-24 20:24:20 ---
I modified a test (0004) with some sample data that confirmed the segfault.
First, in detailed discussions with other developers, the following was
established: it is a DoS, not an exploitable segfault.
> Well it is not that bad, the crash in question is a stack frame
> allocation fault, not access via an invalid pointer, or the like.
> So at best we have a DoS...
...
> Mostly because users will understand an error message about match
> failure due to resource limits, but will waste our time and theirs
> chasing down segfaults.
> But, yes, the DoS is a case of shooting oneself in the foot with
> poorly crafted regexps. We could continue to largely ignore the
> issue and just tell the users to not write patterns like that.
At first I worked with the assumption that manually setting the recursion limit
was the best solution:
> ...thinking that simply calling pcre_exec() with a
> recursion limit is the best solution to prevent the problem. Choosing
> the best size is the next item that would have to be calculated in
> some way
Googling, I came across, some sample code. I saw the pcre_study() function was
called before the pcre_exec() function. I added it and it built fine. It also
ran through the test suite with the same results (4 tests fail for me no matter
what I do).
I used the modified binary and ran lookup against some my modified test (0004)
and it no longer failed. I increased the length of the data string I was
searching from 970 items to 1000, to 2000, and to 10000 items (1118906
characters) and this modified code no longer segfaults.
Attaching a possible patch.
--
Configure bugmail:
http://bugs.exim.org/userprefs.cgi?tab=email
