[mapserver-dev] Fuzzing MapServer

Even Rouault even.rouault at spatialys.com
Sun Jun 13 05:26:10 PDT 2021 

Steve,
> 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”.

The full report with the reproducer becomes public after the grace 
period, like https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16443

> 3) Are there options to using ossfuzz?

ossfuzz itself uses several fuzzing engines (libfuzzer, AFL, honggfuzz). 
Compared to their local execution, what the online service brings is the 
continuous run and the automatic ticketing. I'm not aware of direct 
equivalent to that, and where reports would be kept private.

It could also be integrated with github actions 
(https://google.github.io/oss-fuzz/getting-started/continuous-integration/) 
to test pull requests but that requires to have first run it for several 
weeks to have a relatively bullet proof code base of course. (note: I 
gave that a try with GDAL couple months ago, but hit timeouts as GDAL 
was a too big beast to build. Actually the issue was more on the static 
linking, which is not a requirement anymore. mapserver should fit much 
better. the local build of the Docker image with the fuzzer only takes a 
few minutes)

>
> —Steve
>
> On Sat, Jun 12, 2021 at 6:16 AM Even Rouault 
> <even.rouault at spatialys.com <mailto: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
>     <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 <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
>     <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/
>     <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
>     <https://github.com/MapServer/MapServer/issues/6299> created as
>     remainder)
>     >>>
>     >>>
>     >> --
>     >> http://www.spatialys.com <http://www.spatialys.com>
>     >> My software is free, but my time generally not.
>     >>
>     >> _______________________________________________
>     >> mapserver-dev mailing list
>     >> mapserver-dev at lists.osgeo.org
>     <mailto:mapserver-dev at lists.osgeo.org>
>     >> https://lists.osgeo.org/mailman/listinfo/mapserver-dev
>     <https://lists.osgeo.org/mailman/listinfo/mapserver-dev>
>     >>
>     -- 
>     http://www.spatialys.com <http://www.spatialys.com>
>     My software is free, but my time generally not.
>
-- 
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/437c05be/attachment-0001.html>

More information about the mapserver-dev mailing list