[mapserver-dev] Fuzzing MapServer

[Steve Lime]

I think it’s a great idea to fuzz and I’d be interested on being in on it.
Couple of questions...

1) Sounds like we could start slow with a couple mapfiles and query strings
- and then add to it and test other aspects.
2) What is actually disclosed publicly? The private reports would have
enough info to track down and fix issues, so presumably the specific
request that triggers a bug. Does that level of detail become public? If
so, that’s different then saying more generally that “a specially crafted
request can trigger a memory leak”.
3) Are there options to using ossfuzz?

—Steve

On Sat, Jun 12, 2021 at 6:16 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> Note: the email addresses will be public like in
> https://github.com/google/oss-fuzz/blob/master/projects/gdal/project.yaml
>
> Le 12/06/2021 à 11:27, Seth G a écrit :
> > Hi Even,
> >
> > I think I'm getting the hang of finding/addressing memory leaks so count
> me in - I'll send on a gmail address.
> > I presume we're not expecting 100s of critical security issues that
> would need to be addressed straight after the first run?
> >
> > Seth
> >
> > --
> > web:http://geographika.co.uk
> > twitter: @geographika
> >
> > On Fri, Jun 11, 2021, at 6:25 PM, Even Rouault wrote:
> >> Hi,
> >>
> >> I've a prototype of a fuzzing target that can run under ossfuzz now
> >> working - locally - with the tooling they provide to run locally. I
> >> discovered that they now document how to make it work with shared
> >> libraries
> >> (
> https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/#runtime-dependencies
> ),
> >> which made things a bit easier.
> >>
> >> The current fuzzer basically runs msCGIDispatchRequest() on a mapfile
> >> used by WFS tests, with a request that is built from the fuzzed input
> >> buffer. So it simulates the effect of feeding a (not-so-)random
> >> QUERY_STRING, which is of course the more obvious attack vector. I've
> >> confirmed the fuzzer works since in one minute it found a memleak :-)
> >> Additional fuzzers could potentially be written, like fuzzing the
> >> mapfile itself, or using a larger set of mapfiles than just the one I
> >> picked up.
> >>
> >> So the question now is: do we want to submit this to ossfuzz for
> >> inclusion in their nightly builds & CI ? (issues go public 90 days after
> >> being spotted, or 30 days after beeing fixed)
> >>
> >> Note: I do *not* volunteer to fix all bugs it will report.
> >>
> >> If we go to apply for inclusion in ossfuzz, I'll need a list of email
> >> address (that are associated with a gmail account) from developers/PSC
> >> members interested in accessing the (private) reports.
> >>
> >> Even
> >>
> >> Le 15/04/2021 à 21:20, Even Rouault a écrit :
> >>> Le 15/04/2021 à 19:28, Steve Lime a écrit :
> >>>> I hear what you're saying from a release standpoint. I guess I could
> >>>> have said "initiate a fuzzing effort" as part of the 8.0 release. I
> >>>> like your idea to concentrate on the query string, that represents a
> >>>> pretty big surface depending what the fixed mapfile contains. With
> >>>> oss-fuzz there's a time limit on certain types of bugs before
> >>>> public disclosure, correct?
> >>> Details at
> >>>
> https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/
> >>> . They don't make differences between type of bugs.
> >>>
> >>>
> >>>> That's a bit worrisome if you got slammed and nobody was available to
> >>>> address bugs.
> >>> We might also want to decide what to do if bugs impacting security are
> >>> uncovered (might be hard to decide what is exploitable. a double-free
> >>> can in some circumstances be exploited, but I doubt any of us as the
> >>> expertise to evaluate that)
> >>>> Are there alternatives to oss-fuzz that could be considered (Seth
> >>>> referenced one of them)?
> >>>>
> >>>> Funding would be great although our only source of $'s at the moment
> >>>> is the OSGeo project budget which is really small and partially
> >>>> committed to the TravisCI subscription.
> >>> For the mapserver (non-doc) repo, we're close to be ready to unplug
> >>> Travis-CI now we have a github action job. The remaining thing would
> >>> be to add coveralls support
> >>> (https://github.com/MapServer/MapServer/issues/6299 created as
> remainder)
> >>>
> >>>
> >> --
> >> http://www.spatialys.com
> >> My software is free, but my time generally not.
> >>
> >> _______________________________________________
> >> mapserver-dev mailing list
> >> mapserver-dev at lists.osgeo.org
> >> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
> >>
> --
> http://www.spatialys.com
> My software is free, but my time generally not.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20210613/ff265619/attachment.html>