Security
Headlines
HeadlinesLatestCVEs

Headline

CVE-2022-41719: Many panics/crashes when fuzzing · Issue #31 · shamaton/msgpack

Unmarshal can panic on some inputs, possibly allowing for denial of service attacks.

CVE
#dos

Hi there,

I’ve been fuzzing this library using the excellent go-fuzz fuzzer. It has produced quite a few panics in the Unmarshal functionality. These panics can have security implications and can lead to, for example, denial-of-service. Ideally this library would be resilient to potentially malicious msgpack payloads.

I used the following code to test Unmarshal against fuzzed inputs:

var r interface{}

err = msgpack.Unmarshal(data, &r) if err != nil { panic(err) }

This produced a number of crashes. I see three general types of crashes:

1:panic: runtime error: slice bounds out of range [:6] with capacity 1
1:panic: runtime error: index out of range [23] with length 23
1:panic: runtime error: hash of unhashable type map[interface {}]interface {}

There are many more like this, but they’re the same crash with different values.

I’ve attached a zipfile with files that contain msgpack data that produce the panics. Calling Unmarshal on the data like the above code snippet should reproduce the crashes. Due to potential security implications here, it would be beneficial if this msgpack implementation was resilient to these payloads, and produced errors on invalid input instead of panics. Is it possible to fix the code such that it is?

Thank you for creating this library, and let me know if you have any questions!

crashers.zip

Related news

GHSA-jr77-8gx4-h5qh: MessagePack for Golang subject to DoS via Unmarshal panic

Unmarshal can panic on some inputs, possibly allowing for denial of service attacks. This issue has been patched in version 2.1.1.

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907