8-byte Out of Bounds Write onto the Heap #196
Comments
|
I got a different error when I tried this, but of course it could just be a different manifestation of the same thing. I will post when I've fixed it. |
|
I cannot reproduce this. When I tried your test, it showed up a different error in pcre2test when a string repeat [something]{count} had a ridiculously large count. I have fixed this in HEAD - I now get a clean "realloc() failed" error message from your test, with or without ASAN. I've looked at the code related to the line in pcre2test that you quote, but cannot spot any problem. This is all on Arch Linux. Please can you post the output from pcre2test. That will show which input line is causing your issue. |
|
I think ASAN is either a red herring or another bug. The fix is incomplete though, as HEAD is still crashing in Linux x86, because the underlying problem is an integer overflow in the multiplication to get |
|
Hmm. I do not get a crash - oh, possibly because this is a 64-bit system. Are you talking about 32-bit? I'm not hugely worried about his because pcre2test is, after all, just a test program. We could just put an upper limit on the repetition count. |
|
I believe @carenas is correct and the ASAN is either another issue or red herring. I should have compared the backtraces for both x86 and amd64. When compiled with $ git clean -xfd
$ git log --oneline| head -n 1
303e3bc make sure to use either size_t or PCRE2_SIZE correctly (#195)
$ CC=clang CFLAGS="-m32 -fno-omit-frame-pointer -fno-inline-functions -Og -ggdb -Wl,-rpath=$(pwd)/.libs" LDFLAGS="-m32 -Wl,-rpath=$(pwd)/.libs" ./autogen.sh
$ CC=clang CFLAGS="-m32 -fno-omit-frame-pointer -fno-inline-functions -Og -ggdb -Wl,-rpath=$(pwd)/.libs" LDFLAGS="-m32 -Wl,-rpath=$(pwd)/.libs" ./configure
$ CC=clang CFLAGS="-m32 -fno-omit-frame-pointer -fno-inline-functions -Og -ggdb -Wl,-rpath=$(pwd)/.libs" LDFLAGS="-m32 -Wl,-rpath=$(pwd)/.libs" make -j4
$ checksec .libs/pcre2test
Arch: i386-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: PIE enabled
$ ./pcre2test ./80271ad5c66883facd8415181d5c632ff297b23a45a70760d831d2d8cd4a6ddd.txt
PCRE2 version 10.43-DEV 2023-01-15
!\SP�]\�
�P:�PP|P@|��P|P@|a�!
\���d��ɵ����]\�
No match
�P:�P`|PZ|a�!
0: a\xff
\���d�������
No match
�[dQ[\�]{1666666666666}
No match
�[d\[\�]{1}\���d��ɵ���d]\�
No match
�P:�PT|P@|a�!
0: P@
\���d�������
No match
�[d\[y�]{1666666666}
[1] 197356 segmentation fault (core dumped) LD_LIBRARY_PATH="$(pwd)" ./pcre2testThe backtrace: #0 __memcpy_sse2_unaligned () at ../sysdeps/i386/i686/multiarch/memcpy-sse2-unaligned.S:656
#1 0x5655c075 in process_data () at src/pcre2test.c:6916
#2 0x56559db9 in main (argc=<optimized out>, argv=0xffffd074) at src/pcre2test.c:9441
#3 0xf7d2f519 in __libc_start_call_main (main=main@entry=0x56558da0 <main>, argc=argc@entry=2, argv=argv@entry=0xffffd074) at ../sysdeps/nptl/libc_start_call_main.h:58
#4 0xf7d2f5f3 in __libc_start_main_impl (main=0x56558da0 <main>, argc=2, argv=0xffffd074, init=0x0, fini=0x0, rtld_fini=0xf7fcaaa0 <_dl_fini>, stack_end=0xffffd06c) at ../csu/libc-start.c:392
#5 0x565587eb in _start ()Which points to an issues with memcpy(CAST8VAR(q), start_rep, replen);I tried out the patch made by @carenas and confirmed the segmentation fault no longer exists on x86. $ gh pr checkout 198
$ git log --oneline| head -n 1
e44ca41 add a C23 inspired checked integer multiplication helper
< Same autogen/configure/make as before >
$ ./pcre2test ./80271ad5c66883facd8415181d5c632ff297b23a45a70760d831d2d8cd4a6ddd.txt
PCRE2 version 10.43-DEV 2023-01-15
!\SP�]\�
�P:�PP|P@|��P|P@|a�!
\���d��ɵ����]\�
No match
�P:�P`|PZ|a�!
0: a\xff
\���d�������
No match
�[dQ[\�]{1666666666666}
No match
�[d\[\�]{1}\���d��ɵ���d]\�
No match
�P:�PT|P@|a�!
0: P@
\���d�������
No match
�[d\[y�]{1666666666}
** Expanded content too large
�[d\[\�]{1} 6}\H�6!** Unrecognized escape sequence "\H" |
so, could you reproduce the ASAN issue? and if so, can you validate it has an stacktrace than matches what was originally reported even after applying the current fixes? |
|
I recompiled with ASAN for x86 and amd64 and the issue seems to be resolved. Without further triaging, ASAN must have just picked up the issue at a different point in time. $ git log --oneline| head -n 1
e44ca41 add a C23 inspired checked integer multiplication helper
$ checksec .libs/pcre2test
Arch: i386-32-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: PIE enabled
ASAN: Enabled
UBSAN: Enabled
$ .libs/pcre2test ./80271ad5c66883facd8415181d5c632ff297b23a45a70760d831d2d8cd4a6ddd.txt
PCRE2 version 10.43-DEV 2023-01-15
!\SP�]\�
�P:�PP|P@|��P|P@|a�!
\���d��ɵ����]\�
No match
�P:�P`|PZ|a�!
0: a\xff
\���d�������
No match
�[dQ[\�]{1666666666666}
No match
�[d\[\�]{1}\���d��ɵ���d]\�
No match
�P:�PT|P@|a�!
0: P@
\���d�������
No match
�[d\[y�]{1666666666}
** Expanded content too large
�[d\[\�]{1} 6}\H�6!** Unrecognized escape sequence "\H"
$ checksec .libs/pcre2test
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: PIE enabled
ASAN: Enabled
UBSAN: Enabled
$ .libs/pcre2test ./80271ad5c66883facd8415181d5c632ff297b23a45a70760d831d2d8cd4a6ddd.txt
PCRE2 version 10.43-DEV 2023-01-15
!\SP�]\�
�P:�PP|P@|��P|P@|a�!
\���d��ɵ����]\�
No match
�P:�P`|PZ|a�!
0: a\xff
\���d�������
No match
�[dQ[\�]{1666666666666}
No match
�[d\[\�]{1}\���d��ɵ���d]\�
No match
�P:�PT|P@|a�!
0: P@
\���d�������
No match
�[d\[y�]{1666666666}
No match
�[d\[\�]{1} 6}\H�6!** Unrecognized escape sequence "\H" |
|
could you close this issue then? |
|
Resolved with PR #198. |
Found a small faulting test case for
pcre2testthat causes a segmentation fault on some architectures (x86). It looks like the fault is inprocess_data. The logic for fillingovectormay be off by one. Specifically, the offending line isin the file:line
pcre2test.c:7634I've attached the faulting test case below. Can anyone confirm they get the same result? Low security implications due to mitigations and the size of the overwrite on the heap.
80271ad5c66883facd8415181d5c632ff297b23a45a70760d831d2d8cd4a6ddd.txt
The text was updated successfully, but these errors were encountered: