CBOR-XS

 view release on metacpan or  search on metacpan

Changes  view on Meta::CPAN

	- 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.

README  view on Meta::CPAN


    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.

XS.pm  view on Meta::CPAN


=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 )