[mapserver-dev] Fuzzing MapServer
Even Rouault
even.rouault at spatialys.com
Fri Jun 11 09:25:08 PDT 2021
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.
More information about the mapserver-dev
mailing list