[mapserver-dev] Fuzzing MapServer

[Steve Lime]

The full report is worrisome with a web application when thinking about a
worst case scenario where a security issue is found. I mean you can patch
and release new version(s) with a general disclosure but publishing the
exploit details (the reproducer) seems like a bad idea to me in some cases.
It seems to take awhile for new MapServer versions to take hold so someone
not paying attention could be screwed.

That said, it's potentially super valuable testing...

--Steve

On Sun, Jun 13, 2021 at 7:26 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> 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>
> 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.
>>
>> -- 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/20210614/75f66e97/attachment-0001.html>