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

[Kurt Schwehr]

Kristian,

Thanks for joining OSS Fuzz.  I'm not on that team at Google, but I have
been doing a lot of fuzzing at Google in the last year.  Specifically GDAL
and Kakadu with a touch of GEOS.
https://github.com/schwehr/gdal-autotest2/tree/master/cpp   I live in a
space where code gets a ton of craziness sent at it at high volumns, so I
really appreciate the work you all are doing.

The very definition of undefined behavior means that the compiler is
allowed to do literally whatever it wants.  Common compilers usually try to
give you some value that will keep things moving forward... that makes them
especially difficult to find :(

If you are allowed to use docker (or anything else that will host a virtual
os) on your work machine, that can give you a linux environment where it
will be easier to find some of these.   I know that's often explicitly not
allowed at many places.

It definitely helps to be able to add extra logic and rerun with the same
ASAN setup.

You might also consider the free tier with Google Compute Engine or any of
the other cloud providers like Amazon/RedHat/etc.  I only really know
anything about the Google offerings since that's where I work, but the f1
micro instance is enough to checkout a copy of proj.4 and do some
debugging.  Just know that builds won't be particularly fast.

-Kurt
Engineer at Google

On Tue, May 23, 2017 at 3:50 AM, Kristian Evers <kreve at sdfe.dk> 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.
>
>
>
> 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
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
>



-- 
--
http://schwehr.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20170523/2e0c09e3/attachment-0001.htm