heap buffer overflow (READ of size 13)

[p5pRT]

Migrated from rt.perl.org#133620 (status was 'resolved')

Searchable as RT133620$

[p5pRT]

From geeknik@protonmail.ch

This "crafted" bit of code triggers a heap buffer overflow in Perl v5.29.3-58-g8fc05532ae. A similar bug was fixed with the release of 5.26.0 (71776ae)
./perl -e `echo "L1vfLS9p" | base64 -d`
==26070==ERROR​: AddressSanitizer​: heap-buffer-overflow on address 0x60200000dc54 at pc 0x7fa3aeae7f7f bp 0x7ffecfe8cc40 sp 0x7ffecfe8c3f0
READ of size 13 at 0x60200000dc54 thread T0
  #0 0x7fa3aeae7f7e (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cf7e)
  #1 0x5621c2c47c57 in Perl_sv_vcatpvfn_flags /root/perl/sv.c​:13296
  #2 0x5621c2c5d92b in Perl_sv_vsetpvfn /root/perl/sv.c​:10916
  #3 0x5621c2a9c29c in Perl_vmess /root/perl/util.c​:1484
  #4 0x5621c28ea753 in S_re_croak2 /root/perl/regcomp.c​:20688
  #5 0x5621c29b54c5 in S_regclass /root/perl/regcomp.c​:17323
  #6 0x5621c29deddb in S_regatom /root/perl/regcomp.c​:12964
  #7 0x5621c29f72a0 in S_regpiece /root/perl/regcomp.c​:12028
  #8 0x5621c29f72a0 in S_regbranch /root/perl/regcomp.c​:11956
  #9 0x5621c2a00b90 in S_reg /root/perl/regcomp.c​:11733
  #10 0x5621c29b3cad in S_regclass /root/perl/regcomp.c​:17719
  #11 0x5621c29deddb in S_regatom /root/perl/regcomp.c​:12964
  #12 0x5621c29f72a0 in S_regpiece /root/perl/regcomp.c​:12028
  #13 0x5621c29f72a0 in S_regbranch /root/perl/regcomp.c​:11956
  #14 0x5621c2a27d21 in S_reg /root/perl/regcomp.c​:11687
  #15 0x5621c2a2f484 in Perl_re_op_compile /root/perl/regcomp.c​:7235
  #16 0x5621c269f143 in Perl_pmruntime /root/perl/op.c​:7029
  #17 0x5621c28a5968 in Perl_yyparse /root/perl/perly.y​:1228
  #18 0x5621c26f96d7 in S_parse_body /root/perl/perl.c​:2503
  #19 0x5621c26f96d7 in perl_parse /root/perl/perl.c​:1797
  #20 0x5621c25bf168 in main /root/perl/perlmain.c​:121
  #21 0x7fa3ad9942e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
  #22 0x5621c25c0339 in _start (/root/perl/perl+0x148339)

0x60200000dc54 is located 0 bytes to the right of 4-byte region [0x60200000dc50,0x60200000dc54)
allocated by thread T0 here​:
  #0 0x7fa3aeb4d090 in realloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc2090)
  #1 0x5621c2a98a0f in Perl_safesysrealloc /root/perl/util.c​:271
  #2 0x5621c27e7a5e in S_scan_const /root/perl/toke.c​:4093
  #3 0x5621c27e7a5e in Perl_yylex /root/perl/toke.c​:5069
  #4 0x5621c289e6bd in Perl_yyparse /root/perl/perly.c​:340
  #5 0x5621c26f96d7 in S_parse_body /root/perl/perl.c​:2503
  #6 0x5621c26f96d7 in perl_parse /root/perl/perl.c​:1797
  #7 0x5621c25bf168 in main /root/perl/perlmain.c​:121
  #8 0x7fa3ad9942e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)

SUMMARY​: AddressSanitizer​: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x5cf7e)

[p5pRT]

From @tonycoz

On Thu, 25 Oct 2018 08​:25​:59 -0700, geeknik@​protonmail.ch wrote​:

This "crafted" bit of code triggers a heap buffer overflow in Perl
v5.29.3-58-g8fc05532ae. A similar bug was fixed with the release of
5.26.0
(71776ae)
./perl -e `echo "L1vfLS9p" | base64 -d`
==26070==ERROR​: AddressSanitizer​: heap-buffer-overflow on address
0x60200000dc54 at pc 0x7fa3aeae7f7f bp 0x7ffecfe8cc40 sp
0x7ffecfe8c3f0
READ of size 13 at 0x60200000dc54 thread T0
#0 0x7fa3aeae7f7e (/usr/lib/x86_64-linux-
gnu/libasan.so.3+0x5cf7e)
#1 0x5621c2c47c57 in Perl_sv_vcatpvfn_flags /root/perl/sv.c​:13296
#2 0x5621c2c5d92b in Perl_sv_vsetpvfn /root/perl/sv.c​:10916
#3 0x5621c2a9c29c in Perl_vmess /root/perl/util.c​:1484
#4 0x5621c28ea753 in S_re_croak2 /root/perl/regcomp.c​:20688
#5 0x5621c29b54c5 in S_regclass /root/perl/regcomp.c​:17323
#6 0x5621c29deddb in S_regatom /root/perl/regcomp.c​:12964
#7 0x5621c29f72a0 in S_regpiece /root/perl/regcomp.c​:12028
#8 0x5621c29f72a0 in S_regbranch /root/perl/regcomp.c​:11956
#9 0x5621c2a00b90 in S_reg /root/perl/regcomp.c​:11733
#10 0x5621c29b3cad in S_regclass /root/perl/regcomp.c​:17719
#11 0x5621c29deddb in S_regatom /root/perl/regcomp.c​:12964
#12 0x5621c29f72a0 in S_regpiece /root/perl/regcomp.c​:12028
#13 0x5621c29f72a0 in S_regbranch /root/perl/regcomp.c​:11956
#14 0x5621c2a27d21 in S_reg /root/perl/regcomp.c​:11687
#15 0x5621c2a2f484 in Perl_re_op_compile /root/perl/regcomp.c​:7235
#16 0x5621c269f143 in Perl_pmruntime /root/perl/op.c​:7029
#17 0x5621c28a5968 in Perl_yyparse /root/perl/perly.y​:1228
#18 0x5621c26f96d7 in S_parse_body /root/perl/perl.c​:2503
#19 0x5621c26f96d7 in perl_parse /root/perl/perl.c​:1797
#20 0x5621c25bf168 in main /root/perl/perlmain.c​:121
#21 0x7fa3ad9942e0 in __libc_start_main (/lib/x86_64-linux-
gnu/libc.so.6+0x202e0)
#22 0x5621c25c0339 in _start (/root/perl/perl+0x148339)

0x60200000dc54 is located 0 bytes to the right of 4-byte region
[0x60200000dc50,0x60200000dc54)
allocated by thread T0 here​:
#0 0x7fa3aeb4d090 in realloc (/usr/lib/x86_64-linux-
gnu/libasan.so.3+0xc2090)
#1 0x5621c2a98a0f in Perl_safesysrealloc /root/perl/util.c​:271
#2 0x5621c27e7a5e in S_scan_const /root/perl/toke.c​:4093
#3 0x5621c27e7a5e in Perl_yylex /root/perl/toke.c​:5069
#4 0x5621c289e6bd in Perl_yyparse /root/perl/perly.c​:340
#5 0x5621c26f96d7 in S_parse_body /root/perl/perl.c​:2503
#6 0x5621c26f96d7 in perl_parse /root/perl/perl.c​:1797
#7 0x5621c25bf168 in main /root/perl/perlmain.c​:121
#8 0x7fa3ad9942e0 in __libc_start_main (/lib/x86_64-linux-
gnu/libc.so.6+0x202e0)

SUMMARY​: AddressSanitizer​: heap-buffer-overflow (/usr/lib/x86_64-
linux-gnu/libasan.so.3+0x5cf7e)

Bisects down to :

commit 51684e3
Author​: Karl Williamson <khw@​cpan.org>
Date​: Fri Mar 2 04​:47​:45 2018 -0700

  regcomp.c​: Change error reporting mechanism slightly
 
  There are (rare) constructs which cause regcomp.c to modify the user
  input stream (stashing the original), and that is parsed instead before
  returning to the continue with the original. A problem arises if an
  error occurs during the parsing of this modified version. We want to
  report the location of the error and context based on the original.
  This led to 285b5ca (fixing #126261).
 
  This new commit simplifies the mechanism so that it is easier to
  understand.

:100644 100644 1e8266b67e9d0ce6233af3703aa84d6c4259a8e0 3c09bc713d5fe4042bbda695f899539af644e5a8 M regcomp.c

Tony

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @khwilliamson

Thank you for finding and reporting this

I moved this ticket to the public queue as the bug is not in a stable release.

The problem occurs when a substitute parse string is constructed. Any errors have to be translated back to the terms of the original string. This wasn't happening properly when the error was at the right edge of the new parse string. It has been fixed by commit 232b691

The test I added is slightly different than what the original does, which reduces to

./perl -Dr -e /[<DF>-/i

where <DF> is the literal \xDF. It's a pain getting non-UTF-8 into our test files. So the added test doesn't do that, but still generates valgrind errors before the patch is applied.

--
Karl Williamson

[p5pRT]

@khwilliamson - Status changed from 'open' to 'resolved'