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

On 29 May 2014 10:19, Christopher Horvath <address@hidden> wrote:

I'm in a crippled environment that explicitly disallows exceptions, and has modified underlying some (but not all) underlying libraries accordingly. I worked a bit to try to incorporate these restrictions into the fuzz tests, but ultimately gave up - I'm trusting that the fuzz tests will have been run elsewhere.

Additionally, there's a bug in one of the main tests. In testMultiPartSharedAttributes.cpp, in the testHeaders function, the first call is to:

vector<Header> headers;

// expect this to fail - empty header list
testMultiPartOutputFileForExpectedFailure (headers,

fn,
"Header : empty header list passed");

And then inside the testMultiPartOutputFileForExpectedFailure function, the code takes the address of the 0'th element of the vector, which is invalid for an empty vector, and throws an exception which is not caught:

try
{
remove(fn.c_str());

MultiPartOutputFile file(fn.c_str(), &headers[0],headers.size());
cerr << "ERROR -- " << failMessage << endl;

assert (false);
}
catch (const IEX_NAMESPACE::ArgExc & e)

{
// expected behaviour
}

The &headers[0] is invalid on an empty list, and causes a test failure.

I've just disabled this test locally - all other non-tests succeed.

On Thu, May 29, 2014 at 10:06 AM, Chris Cox <address@hidden> wrote:

That could be because "new" is defined in the language as throwing an
exception if it fails to allocate memory. Doing a NULL check after "new"
would only be necessary if running in a crippled environment that does not
support exceptions.

Malloc/calloc/realloc should never throw, but return NULL if they fail to
allocate memory.

Chris

On 5/28/14 11:57 PM, "Peter Hillman" <address@hidden> wrote:

>
> The OpenEXR fuzz tests insert bytes into files to test what happens with
> accidentally or maliciously damaged files.
> When a "length-of-attribute" field in the EXR Header is modified to be
> an extremely large number, the library will often attempt to allocate a
> large amount of memory to load the supposedly large attribute. There's
> no standard place where this happens; each attribute type manages
> loading the values itself. The field storing type of the attribute may
> also become damaged, causing unusual behaviour.
>
> It seems like the OpenEXR library does rather assume that calls to 'new'
> etc will throw exceptions if they fail, rather than nullptr testing.
> This is in the library itself, rather than the fuzz tests.
>
>
>
>
>
> On 29/05/14 13:26, Nick wrote:
>> Are you saying you have a malloc implementation that crashes if it can't
>> allocate due to not enough memory? Or are you saying that the fuzz test
>> relies on an exception not a nullptr test? If the latter it would be better
>> to modify the test to null test. If the former, what the heck?
>>
>> Fuzz tests generally are supposed to demonstrate that the library can survive
>> malicious exploits like forced overruns or whatever through malformed files.
>>
>> If you are crashing, it's a bad malloc, a bad test, or OpenEXR isn't
>> completely fuzz safe.
>>
>> Or this is a different use of the term fuzz testing that I am not familiar
>> with ;)
>>
>> - Nick
>>
>> Sent from my iPhone
>>
>>> On May 28, 2014, at 15:01, "Christopher Horvath" <address@hidden>
>>> wrote:
>>>
>>> Hey Folks,
>>>
>>> It seems like some of the fuzz tests are explicitly attempting to fail by
>>> creating large allocations and catching exceptions from failed memory
>>> allocations. If you're working with a malloc library that has exceptions
>>> turned off, this causes crashes...
>>>
>>> Is this the correct interpretation of how fuzzScanLines & fuzzFile is
>>> intended to work?
>>>
>>> This seems to be testing that malloc throws correctly - which in my case, it
>>> does not - I just want to make sure I can feel comfortable turning these
>>> fuzz tests off for the future.
>>>
>>> Chris
>>>
>>> --
>>> I think this situation absolutely requires that a really futile and stupid
>>> gesture be done on somebody's part. And we're just the guys to do it.
>>> _______________________________________________
>>> Openexr-devel mailing list
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>> _______________________________________________
>> Openexr-devel mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/openexr-devel
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/openexr-devel

--
I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it.

_______________________________________________
Openexr-devel mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/openexr-devel

From:	Piotr Stanczyk
Subject:	Re: [Openexr-devel] Relying on exceptions in fuzz tests?
Date:	Thu, 29 May 2014 10:21:12 -0700