-
Notifications
You must be signed in to change notification settings - Fork 89
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
Decoder doesn't check output size before allocating #60
Comments
I just confirmed this to still be the case with the current This makes it extremely trivial to craft a DOS package, where you can crash any application feeding a very small zstd payload. |
Thanks for reporting this. Would you help me understand the behavior of For the file that you posted, is the value that it is returning ( Thanks. |
@kevinconaway The input is from a fuzz test. The value is likely from The problem is that you can just set this value to whatever and crash the decoder. You need some sanity validation of this value. |
Fix #60 Before we were blindly trusting the data returned by ZSTD_getDecompressedSize. This mean with a specifically crafter payload, we would try to allocate a lot of memory resulting in potential DOS. Now set a sane limit and fall back to streaming
[zstd][#60] Add decompression size sanity Check
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.12.1 windows/amd64
What operating system and processor architecture are you using (
go env
)?Package version:
809b919c325d7887bff7bd876162af73db53e878
(v.1.4.0 tag)What did you do?
Fuzz test. Using
ref, refErr := zstd.Decompress(nil, data)
.It seems like the decompressor will attempt to allocate whatever value is returned from
ZSTD_getDecompressedSize
, meaning you can crash the decoder with a very small payload. The value is also cast from uint64 toint
allowing negative values, which willpanic: runtime error: makeslice: len out of range
. Note thatint
can also be 32 bits.Sample: a43e4d2eb6da97e23c23964ee90a093262f69564.zst.gz (gzipped to make github happy).
What did you expect to see?
No crash. The decoder should fall back to streaming over a certain size.
What did you see instead?
The text was updated successfully, but these errors were encountered: