heap-buffer-overflow (pad.c:1760:10) in Perl_pad_free #17090

p5pRT · 2019-07-09T09:25:57Z

Migrated from rt.perl.org#134277 (status was 'open')

Searchable as RT134277$

p5pRT · 2019-07-09T09:25:57Z

From imdb95@gmail.com

Hello,
I found this bug when fuzzing perl5.

**********Compilation and environment**********
root@instance-2:~/fuzz_perl# ./perl/perl -v

This is perl 5, version 31, subversion 2 (v5.31.2 (v5.31.1-6-g9649a81))
built for x86_64-linux

Perl may be copied only under the terms of either the Artistic License or
the
GNU General Public License, which may be found in the Perl 5 source kit.

Complete documentation for Perl, including FAQ lists, should be found on
this system using "man perl" or "perldoc perl". If you have access to the
Internet, point your browser at http://www.perl.org/, the Perl Home Page.

root@instance-2:~/fuzz_perl# uname -a
Linux instance-2 4.15.0-1036-gcp #38~16.04.1-Ubuntu SMP Tue Jun 25 15:30:46
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

root@instance-2:~/fuzz_perl# lsb_release -r
Release: 16.04

Compilation:
AFL_USE_ASAN=1 ./Configure -des -Dusedevel -DDEBUGGING -Dcc=afl-clang-fast
-Doptimize=-g && AFL_USE_ASAN=1 make

**Reproduce*
root@instance-2:~/fuzz_perl# cat test.pl
'' =~ /${sub{B{]]]{;_{s}}}}}@0@0/;
root@instance-2:~/fuzz_perl# ./perl/perl test.pl

==16982==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x603000000330 at pc 0x000000716afd bp 0x7ffcae156b40 sp 0x7ffcae156b38
READ of size 8 at 0x603000000330 thread T0
#0 0x716afc in Perl_pad_free /root/fuzz_perl/perl/pad.c:1760:10
#1 0x511363 in Perl_op_clear /root/fuzz_perl/perl/op.c:1251:2
#2 0x50e165 in Perl_op_free /root/fuzz_perl/perl/op.c:914:9
#3 0x6fb753 in Perl_yyparse /root/fuzz_perl/perl/perly.c:546:17
#4 0x5e4235 in S_parse_body /root/fuzz_perl/perl/perl.c:2531:9
#5 0x5da7d5 in perl_parse /root/fuzz_perl/perl/perl.c:1822:2
#6 0x50a36c in main /root/fuzz_perl/perl/perlmain.c:126:10
#7 0x7f5fc044182f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#8 0x4368c8 in _start (/root/fuzz_perl/perl/perl+0x4368c8)

0x603000000330 is located 0 bytes to the right of 32-byte region
[0x603000000310,0x603000000330)
allocated by thread T0 here:
#0 0x4dd5cc in malloc
/scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3
#1 0x88660e in Perl_safesysmalloc /root/fuzz_perl/perl/util.c:155:21

SUMMARY: AddressSanitizer: heap-buffer-overflow
/root/fuzz_perl/perl/pad.c:1760:10 in Perl_pad_free
Shadow bytes around the buggy address:
0x0c067fff8010: 00 02 fa fa 00 00 04 fa fa fa 00 00 04 fa fa fa
0x0c067fff8020: 00 00 01 fa fa fa 00 00 00 01 fa fa 00 00 05 fa
0x0c067fff8030: fa fa 00 00 00 00 fa fa fd fd fd fd fa fa 00 00
0x0c067fff8040: 00 03 fa fa 00 00 00 00 fa fa 00 00 00 05 fa fa
0x0c067fff8050: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 00 fa
=>0x0c067fff8060: fa fa 00 00 00 00[fa]fa 00 00 00 00 fa fa 00 00
0x0c067fff8070: 00 00 fa fa fd fd fd fd fa fa fd fd fd fd fa fa
0x0c067fff8080: fd fd fd fd fa fa 00 00 00 00 fa fa fd fd fd fd
0x0c067fff8090: fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00
0x0c067fff80a0: 00 00 fa fa 00 00 00 00 fa fa 00 00 00 00 fa fa
0x0c067fff80b0: 00 00 00 00 fa fa 00 00 00 00 fa fa 00 00 07 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
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
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
Left alloca redzone: ca
Right alloca redzone: cb
==16982==ABORTING

Please confirm the bug. Crash also happens with default version v5.22.1 of
perl on Ubuntu.

Thanks,
Manh Nguyen

p5pRT · 2019-07-09T10:20:27Z

From @iabyn

On Tue, Jul 09, 2019 at 02:25:57AM -0700, Nguyen Duc Manh wrote:

'' =~ /${sub{B{]]]{;_{s}}}}}@0@0/;

This is feeding code containing a syntax error into the parser.
Again, not a security issue.

--
"Emacs isn't a bad OS once you get used to it.
It just lacks a decent editor."

p5pRT · 2019-07-09T10:20:27Z

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

p5pRT · 2019-08-05T01:44:30Z

From @tonycoz

On Tue, 09 Jul 2019 03:20:27 -0700, davem wrote:

On Tue, Jul 09, 2019 at 02:25:57AM -0700, Nguyen Duc Manh wrote:

'' =~ /${sub{B{]]]{;_{s}}}}}@0@0/;

This is feeding code containing a syntax error into the parser.
Again, not a security issue.

Now public.

Tony

tonycoz · 2020-04-08T00:14:53Z

I haven't been able to reproduce this at the specified commit using afl from git:

$ ./Configure -des -Dusedevel -DDEBUGGING -Doptimize=-g -Dcc=/home/tony/local/afl-git/bin/afl-clang && AFL_USE_ASAN=1 make perl
...
$ ./perl ../17090.pl
syntax error at ../17090.pl line 1, near "{]"
syntax error at ../17090.pl line 1, near "=~ /${sub{B{]]]{;_{s}}}}}@0@0/"
Execution of ../17090.pl aborted due to compilation errors.
$ git describe
v5.31.1-6-g9649a8179c

dur-randir · 2020-04-08T18:15:33Z

It's again html escapes from the converter, proper one is (i've tried to paste code here, but it doesn't work when copied, even when guarded by triple backticks) found in the original report - i've got heap-buffer-overflow diagnostics from it on blead.

tonycoz · 2020-04-09T00:36:08Z

I think the issue was the import process from RT added zero-width spaces after the two @ signs, I can now reproduce it. Let me try pasting it, based on the original message to the list>:

'' =~ /${sub{B{]]]{;_{s}}}}}@0@0/;

Copying that from the preview reproduced it.

tonycoz · 2020-04-22T00:01:38Z

What's happening here is roughly the following sequence:

parsing starts, and PL_curpad/PL_comppad is the pad for the main program, some parsing is done leaving symbols on the shift-reduce stack (this is fine)
a subparse is started, and a new PL_curpad/PL_comppad is created
some tokens are parsed and more symbols pushed onto the shift-reduce stack, including an OP with an op_targ.
parsing fails in the subparse and sublex_done() calls yyquit() which croaks.
scopes are re-wound, resetting PL_curpad/PL_comppad to the main program pad
due to the error, yyparse() cleans up the shift-reduce stack, including calling op_free() on any ops
pad_free() frees the targs allocated on the nested pad from the main program pad, including an entry from beyond the end of the main program pad, which causes the ASAN error.

A kind of a fix would be for sublex_done() to pop the parser stack to where it started from before calling yyquit() but this won't help in the cases where the compilation croaks due to other errors (eg. more than 10 errors.)

I expect the only real fix is start a new parse for a sublex rather than re-using the current parser, as has been suggested before.

iabyn · 2020-04-22T15:01:39Z

On Wed, Apr 22, 2020 at 01:36:15AM +0000, Tony Cook wrote: A kind of a fix would be for sublex_done() to pop the parser stack to where it started from before calling yyquit() but this won't help in the cases where the compilation croaks due to other errors (eg. more than 10 errors.)

My desire is that compiling should abort on the first encountered parse error, rather than trying (badly) to continue. The current behaviour has thrown up many hard-to-fix crashes under fuzzing. We would still allow multiple semantic errors to accumulate; e.g. use strict; $x=1; $y=2; would still output two 'Global symbol "$foo" requires explicit package name' errors.

…

-- Art is anything that has a label (especially if the label is "untitled 1")

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

heap-buffer-overflow (pad.c:1760:10) in Perl_pad_free #17090

heap-buffer-overflow (pad.c:1760:10) in Perl_pad_free #17090

p5pRT commented Jul 9, 2019

p5pRT commented Jul 9, 2019

p5pRT commented Jul 9, 2019

p5pRT commented Jul 9, 2019

p5pRT commented Aug 5, 2019

tonycoz commented Apr 8, 2020

dur-randir commented Apr 8, 2020 •

edited

tonycoz commented Apr 9, 2020

tonycoz commented Apr 22, 2020

iabyn commented Apr 22, 2020 via email

heap-buffer-overflow (pad.c:1760:10) in Perl_pad_free #17090

heap-buffer-overflow (pad.c:1760:10) in Perl_pad_free #17090

Comments

p5pRT commented Jul 9, 2019

p5pRT commented Jul 9, 2019

From imdb95@gmail.com

**********Reproduce********* root@​instance-2​:~/fuzz_perl# cat test.pl '' =~ /${sub{B{]]]{;_{s}}}}}@​0@​0/; root@​instance-2​:~/fuzz_perl# ./perl/perl test.pl

p5pRT commented Jul 9, 2019

From @iabyn

p5pRT commented Jul 9, 2019

p5pRT commented Aug 5, 2019

From @tonycoz

tonycoz commented Apr 8, 2020

dur-randir commented Apr 8, 2020 • edited

tonycoz commented Apr 9, 2020

tonycoz commented Apr 22, 2020

iabyn commented Apr 22, 2020 via email

**Reproduce*
root@instance-2:~/fuzz_perl# cat test.pl
'' =~ /${sub{B{]]]{;_{s}}}}}@0@0/;
root@instance-2:~/fuzz_perl# ./perl/perl test.pl

dur-randir commented Apr 8, 2020 •

edited