------- You are receiving this mail because: ------- You are on the CC list for the bug.
http://bugs.exim.org/show_bug.cgi?id=869 Summary: Unreasonable recursion caused by two nested groups Product: PCRE Version: 7.6 Platform: x86 OS/Version: Linux Status: NEW Severity: security Priority: high Component: Code AssignedTo: [email protected] ReportedBy: [email protected] CC: [email protected] Hello, Using the latest stable Debian's PHP 5.2.6-1+lenny3 (can't use anything newer on this production server, sorry). Note that this malfunction in regular expressions might create exploitable application vulnerabilities (for example, a forum routine to sanitize posts stopped working since PHP 5.2.0 when the 'pcre.backtrack_limit' setting was introduced). So, conservatively, this should be treated as a potential security fix with unknown impact. // Example 1 (OK) // // This code works as expected and outputs: vvvvvvvvvvvvvv/XXX echo preg_replace( '#(v+)+XXX#', 'i', 'vvvvvvvvvvvvvv/XXX'); // Example 2 (issue) // // The following code is the same but it will not work, even though it // should. It will produce just an empty string. The only difference // between this call and the previous call is that the input text is longer // by a single character (instead of 14 'v' characters, there are 15 of // them). echo preg_replace( '#(v+)+XXX#', 'i', 'vvvvvvvvvvvvvvv/XXX'); The PHP function preg_last_error() returns PREG_BACKTRACK_LIMIT_ERROR, which is set when the pcre library returns a PCRE_ERROR_MATCHLIMIT. When you crank up the backtrack limit in pcre, the second example works: pcre.backtrack_limit=1000000 (It's irrelevant, but in case you were curious, the command-line pcre test tool returns "No match" for both of the pieces of data). -- Configure bugmail: http://bugs.exim.org/userprefs.cgi?tab=email -- ## List details at http://lists.exim.org/mailman/listinfo/pcre-dev
