<div dir="auto">I think it’s a great idea to fuzz and I’d be interested on being in on it. Couple of questions...</div><div dir="auto"><br></div><div dir="auto">1) Sounds like we could start slow with a couple mapfiles and query strings - and then add to it and test other aspects.</div><div dir="auto">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”.</div><div dir="auto">3) Are there options to using ossfuzz?</div><div dir="auto"><br></div><div dir="auto">—Steve</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 12, 2021 at 6:16 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Note: the email addresses will be public like in <br>
<a href="https://github.com/google/oss-fuzz/blob/master/projects/gdal/project.yaml" rel="noreferrer" target="_blank">https://github.com/google/oss-fuzz/blob/master/projects/gdal/project.yaml</a><br>
<br>
Le 12/06/2021 à 11:27, Seth G a écrit :<br>
> Hi Even,<br>
><br>
> I think I'm getting the hang of finding/addressing memory leaks so count me in - I'll send on a gmail address.<br>
> I presume we're not expecting 100s of critical security issues that would need to be addressed straight after the first run?<br>
><br>
> Seth<br>
><br>
> --<br>
> web:<a href="http://geographika.co.uk" rel="noreferrer" target="_blank">http://geographika.co.uk</a><br>
> twitter: @geographika<br>
><br>
> On Fri, Jun 11, 2021, at 6:25 PM, Even Rouault wrote:<br>
>> Hi,<br>
>><br>
>> I've a prototype of a fuzzing target that can run under ossfuzz now<br>
>> working - locally - with the tooling they provide to run locally. I<br>
>> discovered that they now document how to make it work with shared<br>
>> libraries<br>
>> (<a href="https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/#runtime-dependencies" rel="noreferrer" target="_blank">https://google.github.io/oss-fuzz/further-reading/fuzzer-environment/#runtime-dependencies</a>),<br>
>> which made things a bit easier.<br>
>><br>
>> The current fuzzer basically runs msCGIDispatchRequest() on a mapfile<br>
>> used by WFS tests, with a request that is built from the fuzzed input<br>
>> buffer. So it simulates the effect of feeding a (not-so-)random<br>
>> QUERY_STRING, which is of course the more obvious attack vector. I've<br>
>> confirmed the fuzzer works since in one minute it found a memleak :-)<br>
>> Additional fuzzers could potentially be written, like fuzzing the<br>
>> mapfile itself, or using a larger set of mapfiles than just the one I<br>
>> picked up.<br>
>><br>
>> So the question now is: do we want to submit this to ossfuzz for<br>
>> inclusion in their nightly builds & CI ? (issues go public 90 days after<br>
>> being spotted, or 30 days after beeing fixed)<br>
>><br>
>> Note: I do *not* volunteer to fix all bugs it will report.<br>
>><br>
>> If we go to apply for inclusion in ossfuzz, I'll need a list of email<br>
>> address (that are associated with a gmail account) from developers/PSC<br>
>> members interested in accessing the (private) reports.<br>
>><br>
>> Even<br>
>><br>
>> Le 15/04/2021 à 21:20, Even Rouault a écrit :<br>
>>> Le 15/04/2021 à 19:28, Steve Lime a écrit :<br>
>>>> I hear what you're saying from a release standpoint. I guess I could<br>
>>>> have said "initiate a fuzzing effort" as part of the 8.0 release. I<br>
>>>> like your idea to concentrate on the query string, that represents a<br>
>>>> pretty big surface depending what the fixed mapfile contains. With<br>
>>>> oss-fuzz there's a time limit on certain types of bugs before<br>
>>>> public disclosure, correct?<br>
>>> Details at<br>
>>> <a href="https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/" rel="noreferrer" target="_blank">https://google.github.io/oss-fuzz/getting-started/bug-disclosure-guidelines/</a><br>
>>> . They don't make differences between type of bugs.<br>
>>><br>
>>><br>
>>>> That's a bit worrisome if you got slammed and nobody was available to<br>
>>>> address bugs.<br>
>>> We might also want to decide what to do if bugs impacting security are<br>
>>> uncovered (might be hard to decide what is exploitable. a double-free<br>
>>> can in some circumstances be exploited, but I doubt any of us as the<br>
>>> expertise to evaluate that)<br>
>>>> Are there alternatives to oss-fuzz that could be considered (Seth<br>
>>>> referenced one of them)?<br>
>>>><br>
>>>> Funding would be great although our only source of $'s at the moment<br>
>>>> is the OSGeo project budget which is really small and partially<br>
>>>> committed to the TravisCI subscription.<br>
>>> For the mapserver (non-doc) repo, we're close to be ready to unplug<br>
>>> Travis-CI now we have a github action job. The remaining thing would<br>
>>> be to add coveralls support<br>
>>> (<a href="https://github.com/MapServer/MapServer/issues/6299" rel="noreferrer" target="_blank">https://github.com/MapServer/MapServer/issues/6299</a> created as remainder)<br>
>>><br>
>>><br>
>> -- <br>
>> <a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
>> My software is free, but my time generally not.<br>
>><br>
>> _______________________________________________<br>
>> mapserver-dev mailing list<br>
>> <a href="mailto:mapserver-dev@lists.osgeo.org" target="_blank">mapserver-dev@lists.osgeo.org</a><br>
>> <a href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
>><br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote></div></div>