[mapserver-dev] Fuzzing MapServer

[Even Rouault]

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.