------- 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 <[email protected]> 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 -- ## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim details at http://www.exim.org/ ##
