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

[Kristian Evers]

Even,

Windows is what I have on hand at work, so there's that... I am sure everything is a lot smoother on Linux. I'll try a bit more on windows and see if it is usable or not. I might modify the code slightly if my effort turn out successful.

I was specifically looking at one of the Division by zero errors (1801) and expected a proper crash, but as you have experienced with GDAL, nothing really happened. Better testing and rejection of input values are definitely a good place to start.

How is the fuzzer generating the input values? Completely at random, or does it somehow get help with setting up the proj-strings?

/Kristian


Fra: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] På vegne af Even Rouault
Sendt: 23. maj 2017 11:56
Til: proj at lists.maptools.org
Emne: Re: [Proj] Submitting proj.4 to Google OSS Fuzz ?


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/a6b9e5ef/attachment.html>