Re: [Openexr-devel] Relying on exceptions in fuzz tests?

[Peter Hillman]

I think in this case the fuzz tests have done what they should: they've shown that there may be issues with Chris' particular setup. This shows there is merit in running them on each platform/configuration where security is essential.

If this is a situation where there's a possibility of damaged files, you'd have to assess whether the issues that the fuzz tests have highlighted are dangerous and whether to take measures to prevent the issues. If they are, Brendan's suggestion of exiting might work. In a closed system which only loads known files, you could confirm the files are valid with a "normal" build of OpenEXR before uploading them to the system. Otherwise, if you can reliably identify the size of the EXR file, you could write a simple header parser to confirm that no attribute size is larger than the file size or the size of available memory. You could then incorporate that parser into the fuzz test to confirm it catches all the broken files before they crash the library.

Incidentally, the repair to my stupid bug in testMultiPartSharedAttributes.cpp would be to change this:

MultiPartOutputFile file(fn.c_str(), &headers[0],headers.size());
to this:

MultiPartOutputFile file(fn.c_str(), headers.size() > 0 ? &headers[0] : NULL , headers.size());
Apologies for that!

On 30/05/14 09:41, Brendan Bolles wrote:

On May 29, 2014, at 12:14 PM, Christopher Horvath wrote:

I'm compiling OpenEXR with exceptions, but the libraries that I am required to link to beneath OpenEXR have the exception behavior disabled (inconsistently).

I'm happy with the results that 2.1.0 passes all the regular tests for all the libraries. The fuzz tests don't work, but in my case, that's okay, I think.

Sounds like it should mostly work.  If "new" has been hacked to return NULL instead of throw an exception, you are going to get crashes in those cases.  But that is unlikely to happen so long as you don't ask the library to do too much buffering (like reading tiled images with Imf::InputFile).  You could override the new operator to try to exit the program gracefully instead of returning NULL and crashing.

Yeah, I think the fuzz tests are pretty platform-independant.  It's not really important that they work on your platform.


Brendan