Security policy, reporting procedures

[val-ms]

How does one report security issues for image-rs projects?

What do you consider to be a security issue? Do you consider a panic when parsing an image to be a security issue?

My project would consider crashing on untrusted user input to be a denial of service vulnerability. So, a panic when parsing a malformed image is a strong concern to us. We are starting to use image-rs and need to know how to report these issues upstream. If you don't consider this sort of thing to be a security issue, then we can just create an issue and perhaps even pull request on the github project for the affected parser. But if you do, then what are your reporting procedures? I would recommend setting up a SECURITY.md file in each project once you define these procedures.

[fintelia]

We consider panics when parsing an image to be bugs. Any PRs to fix them are welcome and we'll try to merge them quickly.

Unfortunately, however, no one has yet put in the energy to extensively fuzz the library (or more to the point, the time consuming step of identifying the root cause and writing patches for all the issues found).

[197g]

As for handling, most of what you describe would be standard issues for the moment.

On top of that: because parsers are pure Rust and thus rather new, most do not support strict allocation limits yet (the core of png, gif, tiff offer that support but it's not a rock-solid promise yet). There's certainly panics or resource-DOS in the standard libraries allocator that can happen as a result as well.

There are plans to steadily, but slowly, improve the guarantes on a subset of parsers by adding to the Limits. This process could really benefit from more eyes and fingers—also in planning how to approach the issue.

If I'm up-to-date with Github's integration we are able to setup Security Advisories and temporary forks with customized permissions for particularly sensitive issues (further guide, more info from Github themselves). If we were to declare one of the parsers/formats to follow strict allocation limit, or strict forward progress support, or panic free execution then those bugs should be treated as sensitive for those decoders.

[val-ms]

Thanks @fintelia and @HeroicKatora. Thanks for the quick response time. Sorry I lagged a bit! I'll share this with my teammate who has one proposed fix for the GIF decoder. He can submit the bug report to the appropriate project.

My project is tied into oss-fuzz for free automated fuzzing on a few of our main APIs that accept untrusted user input. Two of those functions now call into image-rs for a handful of graphics file types, so that's how we encountered our first panic in the GIF parser. Ideally no untrusted input would cause a panic/crash, except perhaps one systems with very limited memory or with extremely large files. Hopefully we can iron out some of the lower-hanging panic-fruit.

If you do end up setting up a security policy in your repositories, as recommended in the linked @HeroicKatora shared, I would note that Github Issues do not have any mechanism for reporting security issues. They don't explicitly say it, but yeah Github doesn't have such a feature. So unless you want to just keep track of it in emails or something, you may wish to to set up some other ticket queue. Daniel Stenberg, of the Curl project, shared with me that they have had a good experience using HackerOne, which is a business focused specifically on security reporting and collaboration between reporters and developers. You can use it to offer bug bounties as well, but it's not required.

[shutton]

PR submitted: image-rs/weezl#30