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.
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
Unmarshal can panic on some inputs, possibly allowing for denial of service attacks. This issue has been patched in version 2.1.1.