[pcre-dev] [Bug 1638] PCRE Library Call Stack Overflow Vulnerability in match()
https://bugs.exim.org/show_bug.cgi?id=1638 Philip Hazel p...@hermes.cam.ac.uk changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Philip Hazel p...@hermes.cam.ac.uk --- I have fixed the bug identified by Zoltan and committed the patch. As nothing more can be done, I am going to close this bug. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1638] PCRE Library Call Stack Overflow Vulnerability in match()
https://bugs.exim.org/show_bug.cgi?id=1638 --- Comment #3 from hhjack rubym...@yeah.net --- It does not seem to be a problem of PHP. I have mailed to them lately about this potential match_limit_recursion thing. Here is what they reply: We cannot do much for it. Increase the stack of your server (apache has an option for that for example) or simplify your regex. One should really not feed pcre with custom inputs :) -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1638] PCRE Library Call Stack Overflow Vulnerability in match()
https://bugs.exim.org/show_bug.cgi?id=1638
--- Comment #4 from Zoltan Herczeg hzmes...@freemail.hu ---
It does not seem to be a problem of PHP.
Trust me it is.
It is true, that you found a bug in PCRE, but the stack overflow is caused by
not setting the match_limit_recursion variable. This variable limits the depth
of pcre stack recursion.
Consider the following pattern:
/((){4096}a)+/
For each 'a', it allocates around a megabyte of stack. PCRE has no idea about
the available stack size without external help, so it does what you ask it to
do: allocates stack.
Match this to a long sequence of 'a'-s. You get the same stack error.
PHP devs want to push this back to the user: One should really not feed pcre
with custom inputs :). Don't execute user stuff is not the best viewpoint
about security, but several projects follows this approach. You can likely
cause stack overflow with recursive calls in php as well.
JIT is probably the best answer for all stack errors. It uses an own memory
space for recursion, and never leaves that space.
--
You are receiving this mail because:
You are on the CC list for the bug.
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 1638] PCRE Library Call Stack Overflow Vulnerability in match()
https://bugs.exim.org/show_bug.cgi?id=1638 Zoltan Herczeg hzmes...@freemail.hu changed: What|Removed |Added CC||hzmes...@freemail.hu --- Comment #1 from Zoltan Herczeg hzmes...@freemail.hu --- The PCRE interpreter uses stack for recursion, and the machine stack can be exhausted with well crafted patterns (those awful left recursive (?BracketIndex) recursions...). The general solution is correctly setting match_limit_recursion. PHP should _really_ do this. However, this particular pattern revealed a bug in the zero length recursion detector: re /^(?:(?(1)x|)+)+$()/B -- 0 33 Bra 3 ^ 4 17 Bra 7 8 SCond 10 1 Cond ref 13 x 15 3 Alt 18 11 KetRmax 21 17 KetRmax 24 $ 25 5 CBra 1 30 5 Ket 33 33 Ket 36 End -- The second Bra (after 4 17) should be SBra. Anyway, the serious problem is not setting the match_limit_recursion correctly. -- You are receiving this mail because: You are on the CC list for the bug. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
