Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Many panics/crashes when fuzzing #31

Closed
rc-mattschwager opened this issue Aug 22, 2022 · 4 comments
Closed

Many panics/crashes when fuzzing #31

rc-mattschwager opened this issue Aug 22, 2022 · 4 comments
Labels
bug Something isn't working

Comments

@rc-mattschwager
Copy link

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

@github-actions
Copy link

github-actions bot commented Oct 6, 2022

This issue is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale label Oct 6, 2022
@shamaton shamaton removed the stale label Oct 6, 2022
@shamaton
Copy link
Owner

shamaton commented Oct 6, 2022

sorry for delay.
I'm investigating now.

@shamaton
Copy link
Owner

fixed by #32
so close this issue.

@rc-mattschwager
Copy link
Author

Nice! Thank you for looking into this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants