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

[Thomas Knudsen]

In IEEE754 arithmetic, division by zero results in +/- infinity, not by a
crash.

Hence, crashes are only expected if dividing by integer zero, as
demonstrated below:

$ cat IEEE754_division_by_zero.c

#include <stdio.h>

int main (void) {
  double dresult, dzero = 0, dten = 10;
    int    iresult, izero = 0, iten = 10;
  puts ("Dividing by double zero");
  dresult = dten / dzero;
  printf ("dresult = %g\n", dresult);
  puts ("Dividing by integer zero");
  iresult = iten / izero;
  printf ("iresult = %d\n", iresult);
}

$ gcc ieee754division_by_zero.c
$ a
Dividing by double zero
dresult = 1.#INF
Dividing by integer zero

$

2017-05-23 12:50 GMT+02:00 Kristian Evers <kreve at sdfe.dk>:

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