[mapserver-dev] Fuzzing MapServer

[Seth G]

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
>