[Proj] Submitting proj.4 to Google OSS Fuzz ?

[Even Rouault]

On mardi 23 mai 2017 11:29:01 CEST Even Rouault wrote:
> On mardi 23 mai 2017 08:49:29 CEST Kristian Evers wrote:
> > Even,
> > 
> > Good news, indeed. And a bunch of bugs has already been found!
> > 
> > I am trying to reproduce them on my own system and struggling a bit on
> > how. If I
> understand correctly I am supposed to compile the fuzzing target like so:
> > > g++ -g -std=c++11 standard_fuzzer.cpp -o standard_fuzzer -DSTANDALONE
> > > ../../src/.libs/libproj.a -lpthread
> > 
> > And then run the executable with the reproducer testcase file from
> > OSS-Fuzz. After a bit of modification I got the standard_fuzzer working
> > on my system (win7+mingw), but I don't know how to interpret the output
> > when I run the program against the testcase. Everything seem to exit
> > gracefully with return code 0. Is this normal or should I expect the
> > program to crash in a noisy way?
> 
> Kristian,
> 
> You may get obvious crashes in some cases, but some errors are memory leaks
> or more subtle memory misuses that will generally not result in a crash. I
> wouldn't use Windows to debug that (or perhaps with DrMemory ?) , but
> rather Linux + Valgrind Or try building with -fsanitize=address,undefined
> in CFLAGS and LDFLAGS (that's what OSS Fuzz uses to detect issues) if they
> are supported on mingw

I see a number of division by zero issues are reported. From my experience now with GDAL 
and OSS Fuzz, a number of them will not cause runtime crash. For example, when it is a 
floating point division by zero (contrary to integer division by zero which lead to crash). 
Apparently -fsanitize=undefined considers this as undefined behaviour.
I haven't looked at the details of the issues but perhaps we lack some validation of 
parameters and should probably refuse crazy values at pj_init() time (although I can see some 
validation done in pj_ell_set). More generally we should try to validate what we can at 
initialization time rather than in the forward or reverse methods of projections.

More generally I'd expect we have a lack of rubustness regarding those rather pedantic 
undefined behaviour warnings when feeding infinity, NaN and other such inputs either in 
proj.4 string or in coordinates (but given the way the fuzzer likely works, I don't think it is 
likely to try feeding "nan" or "inf" strings in the fuzzed input since nothing in the code 
compares against those strings. Perhas they should be added in a dictionary to make them 
more likely if we want to test for that)
It is also possible to whitelist / blacklist the type of sanitizers we want to use.
See the 'sanitizers' attribute of the project.yaml file: https://github.com/google/oss-fuzz/
blob/master/docs/new_project_guide.md

Even


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170523/857b4a7f/attachment.html>