search

FasterXML / jackson-dataformats-binary

Uber-project for standard Jackson binary format backends: avro, cbor, ion, protobuf, smile
Apache License 2.0
316 stars 136 forks source link

Uncaught validation problem wrt Smile "BigDecimal" type (found by OSS-Fuzzer) #257

Closed cowtowncoder closed 3 years ago

cowtowncoder commented 3 years ago

(note: offshoot of this finding https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=32168)

Looks like following 7-byte document encoding a single "BigInteger" value:

0x3A 0x29 0x0A  0x08  // 4 byte header (note, 0x8 specifies unused bit that... maybe should error)
0x2A // Number, BigDecimal
0xFF // scale; zigzag value of -32,
   // HOWEVER, not actually legal as second-most-significant-bit SHOULD be zero
   // (should this be caught, reported?)
   // -- should be 0xBF
0xC0 // length of payload, zigzag of 0 but similarly invalid represention
   // -- should be 0x80

causes an exception within BigInteger, attempting to pass 0-byte array to construct BigInteger (to further create BigDecimal). That is not a valid value and needs to be specifically checked against, reported.

cowtowncoder commented 3 years ago

One change for more robust handling: allow zero-length payload for BigInteger (value, or unscaled part) to represent BigInteger.ZERO and BigDecimal.ZERO respectively. Since rules regarding this particular potential encoding were not spelled out, seems safest to do this instead of exception.