Untrusted input passed to CBOR Unmarshal() without bounds checking

[tolginator]

Function "UnmarshalCBOR" in file cbor.go calls decMode.Unmarshal() from the cbor module library without any input validation beyond basic checks like nil and zero-length.

The untrusted and potentially malicious input []byte is passed to CBOR library functions via the decMode.Unmarshal/decoder.value/decoder.parseToValue/decoder.getHead call path. The parseToValue() and getHead() functions expect well-formed input and don't perform bounds checking. While I have not verified, it seems possible that malicious input can be constructed to trigger unexpected behavior in the CBOR library. CBOR library's internal methods appear to perform adequate validation, though. The go-cose library must validate user input before passing that onto the Unmarshal() function.

[x448]

While I have not verified, it seems possible that malicious input can be constructed to trigger unexpected behavior in the CBOR library.

@tolginator if you find any reproducer (ideally bad CBOR data that's small) which would cause a crash or other unexpected behavior during decoding, then I think @fxamacker would be very happy to resolve it quickly.

She created the CBOR library (fxamacker/cbor) primarily because other CBOR libraries crashed when decoding malicious CBOR data.

[yogeshbdeshpande]

Besides the basic checks like nil and zero-length, it is the responsibility of the CBOR library to resolve any unexpected invalid input, as mentioned by @x448.

We close this issue. Please reopen if you think it does not address your concern fully.