CBOR-XS
view release on metacpan or search on metacpan
- Math::BigInt and Math::BigFloat are pretty broken (again),
so disable some tests. (try printing the bigfloat
799999999999999999998E99999999999999999998).
1.8 Sun Nov 29 22:35:13 CET 2020
- experimental support for some type casts, as well as embedding
raw cbor data.
1.71 Thu Nov 15 20:52:13 CET 2018
- work around what smells like a perl bug w.r.t. exceptions
thrown in callbacks.
- update libecb.
1.7 Tue Jun 27 04:02:23 CEST 2017
- SECURITY FIX: fix two bugs found by american fuzzy lop,
upgrade is advised if you accept data from untrusted
sources.
- an out-of bound sharedref or stringref index could cause an
out of bounds access - might be exploitable.
- a decoding error during indefinite array or hash decoding
could cause an endless loop.
Longer version: When you are using CBOR in a protocol, talking to
untrusted potentially hostile creatures requires some thought:
Security of the CBOR decoder itself
First and foremost, your CBOR decoder should be secure, that is,
should not have any buffer overflows or similar bugs that could
potentially be exploited. Obviously, this module should ensure that
and I am trying hard on making that true, but you never know.
CBOR::XS can invoke almost arbitrary callbacks during decoding
CBOR::XS supports object serialisation - decoding CBOR can cause
calls to *any* "THAW" method in *any* package that exists in your
process (that is, CBOR::XS will not try to load modules, but any
existing "THAW" method or function can be called, so they all have
to be secure).
Less obviously, it will also invoke "TO_CBOR" and "FREEZE" methods -
even if all your "THAW" methods are secure, encoding data structures
from untrusted sources can invoke those and trigger bugs in those.
=over 4
=item Security of the CBOR decoder itself
First and foremost, your CBOR decoder should be secure, that is, should
not have any buffer overflows or similar bugs that could potentially be
exploited. Obviously, this module should ensure that and I am trying hard
on making that true, but you never know.
=item CBOR::XS can invoke almost arbitrary callbacks during decoding
CBOR::XS supports object serialisation - decoding CBOR can cause calls
to I<any> C<THAW> method in I<any> package that exists in your process
(that is, CBOR::XS will not try to load modules, but any existing C<THAW>
method or function can be called, so they all have to be secure).
Less obviously, it will also invoke C<TO_CBOR> and C<FREEZE> methods -
even if all your C<THAW> methods are secure, encoding data structures from
untrusted sources can invoke those and trigger bugs in those.
( run in 3.868 seconds using v1.01-cache-2.11-cpan-9b1e4054eb1 )