[pcre-dev] [Bug 2761] DFA partial matching does not yield same results as non-partial
https://bugs.exim.org/show_bug.cgi?id=2761 --- Comment #2 from S. Shuck --- Thanks for investigating. Maybe I'm not understanding the concept behind the restart feature, but I respectfully disagree about it not being clever. Ideally we could use the general-purpose workspace for all match algorithm state to make it fully resumable, no? Seems like an implementation shortcoming, not a theoretical one. -- 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
Re: [pcre-dev] Capture not reset inside recursion
Hi ND, On Sun, 6 Jun 2021 at 16:09, ND via Pcre-dev wrote: > > > On 2021-06-06 05:53, Zoltán Herczeg wrote: > > ND I think you have found a pretty nice Perl bug, maybe you could report > > it to them. > > Zoltan, thank you for great investigation. > Now I sure it looks like a Perl bug. > > Everybody feel free to report it. My English is bad and I have much > difficulties with reporting and further conversation. I've done it here https://github.com/Perl/perl5/issues/18865 . Kudos to you and Zoltán for the analysis, and thank you very much for contributing to Perl and PCRE :) Cheers, -- Giuseppe D'Angelo -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
Re: [pcre-dev] Capture not reset inside recursion
On 2021-06-06 05:53, Zoltán Herczeg wrote: ND I think you have found a pretty nice Perl bug, maybe you could report it to them. Zoltan, thank you for great investigation. Now I sure it looks like a Perl bug. Everybody feel free to report it. My English is bad and I have much difficulties with reporting and further conversation. -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 2765] pcretest.c in PCRE 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow)
https://bugs.exim.org/show_bug.cgi?id=2765 Giuseppe D'Angelo changed: What|Removed |Added CC||dange...@gmail.com --- Comment #4 from Giuseppe D'Angelo --- Couple of considerations. The first is whether this is actually exposing a bug in pcre_dfa_exec (using pcretest to demonstrate it), or "merely" a bug in pcretest. Given the input is clearly coming out of a fuzzing test, I can't discern it easily, so it's hard for me to say. Having a minimal C example for this sort of things would be much better. (Having said that, the code in pcretest looks "innocent" enough at a quick glance, so maybe this is really about pcre_dfa_exec passing wrong offsets to the callout, causing a out of bounds read by pcretest's callout callback.) This issue is security-related only if it involves pcre_dfa_exec; if it's a pcretest-only bug, then it's not. pcretest is not supposed to be used to run untrusted inputs. It's a testing facility for PCRE itself, and a quick helper to try regexps out (if you don't like running perl, or going to regex101, etc.), but it's by no means an utility that you should expose to possible attackers. (I'd wager that you shouldn't expose untrusted regexps to possible attackers ANYHOW, as one could easily build regexps that will run for a long time, easily causing a DOS attack.) The second consideration is, of course, that this is about PCRE1, which has reached EOL. Unless this is also reproducible in PCRE2, it's unlikely that you'll see a fix for this. Thanks, -- 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 2764] Regression in JIT matching with ^
https://bugs.exim.org/show_bug.cgi?id=2764 --- Comment #3 from Giuseppe D'Angelo --- Hi Zoltan, Thank you for the explanation (and the quick fix). Given PCRE releases every ~6 months and this bug is affecting quite some users, would you recommend that packagers, distributions etc. cherry pick the r1315 patch (probably some of the earlier ones as well) on top of 10.37? (I have no idea of how much work goes into preparing a release, so I wouldn't ask to rush one out "ASAP" because of this bug.) Thanks again, -- 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 2767] New: can we add MaxNameCount and MaxNameLength in pcre2_config as well as export function
https://bugs.exim.org/show_bug.cgi?id=2767 Bug ID: 2767 Summary: can we add MaxNameCount and MaxNameLength in pcre2_config as well as export function Product: PCRE Version: 10.37 (PCRE2) Hardware: x86-64 OS: Windows Status: NEW Severity: wishlist Priority: medium Component: Code Assignee: philip.ha...@gmail.com Reporter: loquat...@qq.com CC: pcre-dev@exim.org i found the source code have no such export functions to make the setting pcre2_set_max_name_count pcre2_set_max_name_length i think this maybe need for some scenes, hope you to add these two export functions as well as pcre2_config Options. -- 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 2765] pcretest.c in PCRE 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow)
https://bugs.exim.org/show_bug.cgi?id=2765 --- Comment #3 from chengxianglin <670605...@qq.com> --- Created attachment 1391 --> https://bugs.exim.org/attachment.cgi?id=1391=edit poc file How to Reproduce this bug: cat poc | ./pcretest -- 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
Re: [pcre-dev] Capture not reset inside recursion
I agree with Zoltan. I do not think this is a bug. Regards, Philip On Sat, 5 Jun 2021 at 23:43, ND via Pcre-dev wrote: > > Here is pcretest listing: > > > PCRE2 version 10.35 2020-05-09 > /(?:(a)?\1)+/ > aaa > 0: aaa > > > Expected result: > 0: aa > > Perl result: > 0: aa > > -- > ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev > -- ## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
[pcre-dev] [Bug 2765] pcretest.c in PCRE 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow)
https://bugs.exim.org/show_bug.cgi?id=2765 --- Comment #2 from Philip Hazel --- *** Bug 2766 has been marked as a duplicate of 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 2766] pcretest.c in PCRE before 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow)
https://bugs.exim.org/show_bug.cgi?id=2766 Philip Hazel changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Philip Hazel --- *** This bug has been marked as a duplicate of bug 2765 *** -- 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 2765] pcretest.c in PCRE 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow)
https://bugs.exim.org/show_bug.cgi?id=2765 --- Comment #1 from Philip Hazel --- PCRE1 (the 8.xx series) is at end of life. PCRE2 (the 10.xx series, first released in 2015) is where current development is happening. There is unlikely ever to be another 8.xx release. Also, pcretest is a local test program that is not privileged in any way, so I do not understand your summary of this issue. -- 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 2766] New: pcretest.c in PCRE before 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow)
https://bugs.exim.org/show_bug.cgi?id=2766 Bug ID: 2766 Summary: pcretest.c in PCRE before 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow) Product: PCRE Version: 8.44 Hardware: x86-64 OS: Linux Status: NEW Severity: bug Priority: medium Component: Documentation Assignee: philip.ha...@gmail.com Reporter: 670605...@qq.com CC: pcre-dev@exim.org Hello, We found a heap-based buffer overflow bug in the pcretest.c(PCRE before 8.44) , . How to Reproduce: cat poc | ./pcretest ==33844==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62d12400 at pc 0x004023a7 bp 0x7ffd101463a0 sp 0x7ffd10146390 READ of size 1 at 0x62d12400 thread T0 #0 0x4023a6 in pchars /pcre-8.44/pcretest.c:2045 #1 0x402a00 in callout /pcre-8.44/pcretest.c:2272 #2 0x441f37 in internal_dfa_exec /pcre-8.44/pcre_dfa_exec.c:3080 #3 0x444121 in pcre_dfa_exec /pcre-8.44/pcre_dfa_exec.c:3618 #4 0x40d1b1 in main /pcre-8.44/pcretest.c:5214 #5 0x7f917c87983f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) #6 0x4019d8 in _start (/pcre-8.44/pcretest+0x4019d8) 0x62d12400 is located 0 bytes to the right of 32768-byte region [0x62d0a400,0x62d12400) allocated by thread T0 here: #0 0x7f917ccbb961 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98961) #1 0x40a3d0 in main /pcre-8.44/pcretest.c:4593 #2 0x7f917c87983f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) SUMMARY: AddressSanitizer: heap-buffer-overflow /pcre-8.44/pcretest.c:2045 pchars Shadow bytes around the buggy address: 0x0c5a7fffa430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5a7fffa440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5a7fffa450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5a7fffa460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5a7fffa470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c5a7fffa480:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa490: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa4a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa4b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa4c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa4d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==33844==ABORTING -- 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 2765] New: pcretest.c in PCRE 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow)
https://bugs.exim.org/show_bug.cgi?id=2765 Bug ID: 2765 Summary: pcretest.c in PCRE 8.44 allows remote attackers to cause a denial of service (heap-based buffer overflow) Product: PCRE Version: 8.44 Hardware: x86-64 OS: Linux Status: NEW Severity: bug Priority: medium Component: Documentation Assignee: philip.ha...@gmail.com Reporter: 670605...@qq.com CC: pcre-dev@exim.org ==33844==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62d12400 at pc 0x004023a7 bp 0x7ffd101463a0 sp 0x7ffd10146390 READ of size 1 at 0x62d12400 thread T0 #0 0x4023a6 in pchars /pcre-8.44/pcretest.c:2045 #1 0x402a00 in callout /pcre-8.44/pcretest.c:2272 #2 0x441f37 in internal_dfa_exec /pcre-8.44/pcre_dfa_exec.c:3080 #3 0x444121 in pcre_dfa_exec /pcre-8.44/pcre_dfa_exec.c:3618 #4 0x40d1b1 in main /pcre-8.44/pcretest.c:5214 #5 0x7f917c87983f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) #6 0x4019d8 in _start (/pcre-8.44/pcretest+0x4019d8) 0x62d12400 is located 0 bytes to the right of 32768-byte region [0x62d0a400,0x62d12400) allocated by thread T0 here: #0 0x7f917ccbb961 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98961) #1 0x40a3d0 in main /pcre-8.44/pcretest.c:4593 #2 0x7f917c87983f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2083f) SUMMARY: AddressSanitizer: heap-buffer-overflow /pcre-8.44/pcretest.c:2045 pchars Shadow bytes around the buggy address: 0x0c5a7fffa430: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5a7fffa440: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5a7fffa450: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5a7fffa460: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c5a7fffa470: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c5a7fffa480:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa490: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa4a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa4b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa4c0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c5a7fffa4d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==33844==ABORTING -- 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
Re: [pcre-dev] Capture not reset inside recursion
I did more investigation:
Perl:
/(?:(?:(a)b)?\1)+/ matches abaa
/(?:(?:(ab))?\1)+/ does not match ababab
These pattern / input pairs match in PCRE2. I am pretty sure (?:(P))? is
rewritten to ((?:P)?) in Perl, which is valid in some cases, but not in all
cases. ND I think you have found a pretty nice Perl bug, maybe you could report
it to them.
Regards,
Zoltan
Eredeti levél
Feladó: Zoltán Herczeg < hzmes...@freemail.hu (Link ->
mailto:hzmes...@freemail.hu) >
Dátum: 2021 június 6 07:21:30
Tárgy: Re: [pcre-dev] Capture not reset inside recursion
Címzett: Pcre-dev@exim.org < nad...@mail.ru (Link -> mailto:nad...@mail.ru) >
The title is misleading, that feature is a JavaScript thing:
/(?:(a)b|\1)+/ matches aba in Perl, but not in JavaScript.
Anyway it looks like the problem here is ()? clears the capturing bracket in
Perl when the empty case is selected while restores its previous value in PCRE2.
Matching /(?:(a)??b)+/ to abb also has this difference: the capturing bracket
is empty in Perl, while set to a in PCRE2.
Even more interesting that /(?:(?:(a))??\1)+/ only matches to aa as well, while
the body of the ?? should not be matched in the second iteration.
Let's do some debugging:
Match /(?:(?{ print "<$1>" })(?:(a))??(?{ print "[$1]" })\1)+/ to aaa
Output:
<>[][a][][a]
It the second iteration, the capturing bracket contains a before the ?? is
executed, and reset to nothing after.
You will not belive this, but /(?:(?:(?{ print "!" })(a))?\1)+/ matches to aaa
similar to PCRE2. The code block should have zero effect on the matching, still
it disables something (probably an optimization) and works as expected.
Is this a perl bug?
Regards,
Zoltan
Eredeti levél
Feladó: ND via Pcre-dev < pcre-dev@exim.org (Link -> mailto:pcre-dev@exim.org) >
Dátum: 2021 június 6 00:44:08
Tárgy: [pcre-dev] Capture not reset inside recursion
Címzett: Pcre-dev@exim.org (Link -> mailto:Pcre-dev@exim.org)
Here is pcretest listing:
PCRE2 version 10.35 2020-05-09
/(?:(a)?\1)+/
aaa
0: aaa
Expected result:
0: aa
Perl result:
0: aa
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
--
## List details at https://lists.exim.org/mailman/listinfo/pcre-dev
