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

Memory exhaustion and crash on malformed input #29

Closed
Shnatsel opened this issue Feb 27, 2019 · 2 comments · Fixed by #32
Closed

Memory exhaustion and crash on malformed input #29

Shnatsel opened this issue Feb 27, 2019 · 2 comments · Fixed by #32

Comments

@Shnatsel
Copy link

Decoding any of the attached files triggers a crash with the following error message: memory allocation of 136902082592 bytes failedAborted

tiff-oom-crashes.zip

The exact reproduction code can be found in #28. Found via AFL.rs, tested on image-tiff version 0.2.2

Most decoding libraries face this issue at some point. This is usually solved by limiting the amount of allocated memory to some sane default, and letting people override it if they're really dealing with enormous amounts of data. In Rust we can easily allow the API user to override these limits via the builder pattern.

See https://libpng.sourceforge.io/decompression_bombs.html for more info on how a similar issue was solved in libpng. See also the Limits struct from flif crate.

@birktj
Copy link
Member

birktj commented Feb 27, 2019

Thanks for the bug report! I think that using a Limits struct is a good idea, but instead of limiting image width and height like in image-png, we should probably limit the size of a DecodingBuffer. This is so we can use limits in a good way together with #26. When I was working on image-rs/image#860 I had to remove the limits completely so that it would be possible to decode large images, now I probably have to go back and take another look at that.

@Shnatsel
Copy link
Author

I'm pretty sure image-png will accept a PR to set limits via buffer size instead of image dimensions, especially if you have a good rationale. The current solution was a result of a push to get something done after months and months of inactivity.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants