Package: libpcre3 Version: 7.8-2 Severity: important Tags: security Hello, I stumbled over a regular expression use with preg_replace from php that causes preg_replace to never return but actually segfault in libpcre3.
A very simple test-case in php is attached (note I know that this regex is far
from ideal, I didn't write it so don't blame me ;-)
Backrace for pcre:
Program received signal SIGSEGV, Segmentation fault.
match (eptr=0x99d76d 'A' <repeats 200 times>..., ecode=0x9c4295 "U",
mstart=0x99a588 "[color=#00FF00]foobar", 'A' <repeats 179 times>...,
offset_top=8,
md=0x7fffffffad30, ims=1, eptrb=0x0, flags=0, rdepth=12761) at
pcre_exec.c:431
431 pcre_exec.c: No such file or directory.
in pcre_exec.c
(gdb) bt full
#0 match (eptr=0x99d76d 'A' <repeats 200 times>..., ecode=0x9c4295 "U",
mstart=0x99a588 "[color=#00FF00]foobar", 'A' <repeats 179 times>...,
offset_top=8,
md=0x7fffffffad30, ims=1, eptrb=0x0, flags=0, rdepth=12761) at
pcre_exec.c:431
rrc = <value optimized out>
i = <value optimized out>
c = <value optimized out>
utf8 = <value optimized out>
minimize = <value optimized out>
possessive = <value optimized out>
callpat = <value optimized out>
data = <value optimized out>
next = <value optimized out>
prev = <value optimized out>
saved_eptr = <value optimized out>
new_recursive = Cannot access memory at address 0x7fffff7fefd0
Not sure if it helps, valgrind:
==9871== 172,032 bytes in 21 blocks are possibly lost in loss record 6,063 of
6,067
==9871== at 0x4C221A7: malloc (vg_replace_malloc.c:195)
==9871== by 0x5294702: allocator_alloc (in /usr/lib/libapr-1.so.0.3.8)
==9871== by 0x529501F: apr_pool_create_ex (in /usr/lib/libapr-1.so.0.3.8)
==9871== by 0x5066D56: apr_hook_sort_all (apr_hooks.c:195)
==9871== by 0x43EFCC: ap_setup_prelinked_modules (config.c:704)
==9871== by 0x427F78: main (main.c:489)
==9871==
==9871== 204,800 bytes in 25 blocks are possibly lost in loss record 6,065 of
6,067
==9871== at 0x4C221A7: malloc (vg_replace_malloc.c:195)
==9871== by 0x5294702: allocator_alloc (in /usr/lib/libapr-1.so.0.3.8)
==9871== by 0x5294B94: apr_palloc (in /usr/lib/libapr-1.so.0.3.8)
==9871== by 0x5290E28: apr_file_open (in /usr/lib/libapr-1.so.0.3.8)
==9871== by 0x42C74A: ap_pcfg_openfile (util.c:904)
==9871== by 0x43E23C: process_resource_config_nofnmatch (config.c:1648)
==9871== by 0x43E800: ap_process_resource_config (config.c:1759)
==9871== by 0x431A45: include_config (core.c:2601)
==9871== by 0x43CE31: invoke_cmd (config.c:787)
==9871== by 0x43D8C5: ap_build_config_sub (config.c:1438)
==9871== by 0x43DB21: ap_build_config (config.c:1221)
==9871== by 0x43E30F: process_resource_config_nofnmatch (config.c:1656)
==9871==
==9871== LEAK SUMMARY:
==9871== definitely lost: 0 bytes in 0 blocks
==9871== indirectly lost: 0 bytes in 0 blocks
==9871== possibly lost: 1,223,383 bytes in 2,457 blocks
==9871== still reachable: 2,076,903 bytes in 12,396 blocks
==9871== suppressed: 0 bytes in 0 blocks
I expect some kind of stack recursion to be the problem. I am not really sure
about the impact
and reason at the moment and debugging this is not an easy task for me. For now
I added the security tag until it's clear what the impact is. Better save than
sorry.
Feel free to downgrade if you don't agree.
Tested with 7.8-3 on amd64 and i386.
Cheers
Nico
--
Nico Golde - http://www.ngolde.de - [email protected] - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.
<<attachment: la.php>>
pgpFjo4HUirNq.pgp
Description: PGP signature
