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

[Even Rouault]

On mardi 23 mai 2017 10:50:52 CEST Kristian Evers wrote:
> 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.

Perhaps you can install VirtualBox and a Ubuntu/whatever distro image in it ? But for some of 
the errors the log is in the ticket is already a good start.

> 
> 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.

Yes this is a floating point division. On Intel-like CPUs, floating point divisions by zero don't 
raise exceptions by default.

> 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?

No, not completely at random, that's all the interest ! It instruments the code during 
compilation and at runtime observes which branches are taken or not given the input. So it 
favors new inputs that increase code coverage. I suspect also there's some instrumentation 
of strcmp(x, "SOME_LITERAL") calls to add SOME_LITERAL in the dictionary. When you 
locally run oss-fuzz and you look at the logs, it is obvious it detects the basic elements of a 
proj.4 strings like "init", parameter names and projection names.

> 
> /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
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/proj/attachments/20170523/88bb5bb2/attachment.html>