<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Steve,
<blockquote type="cite"
cite="mid:CAMrKZ9-jJS-LxSgcMT2qFuab-16RPjy4ad58Kdr=+vGhjzso2A@mail.gmail.com">
<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>
</blockquote>
<p>The full report with the reproducer becomes public after the
grace period, like
<a class="moz-txt-link-freetext" href="https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16443">https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16443</a><br>
</p>
<blockquote type="cite"
cite="mid:CAMrKZ9-jJS-LxSgcMT2qFuab-16RPjy4ad58Kdr=+vGhjzso2A@mail.gmail.com">
<div dir="auto">3) Are there options to using ossfuzz?</div>
</blockquote>
<p>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.<br>
</p>
<p>It could also be integrated with github actions
(<a class="moz-txt-link-freetext" href="https://google.github.io/oss-fuzz/getting-started/continuous-integration/">https://google.github.io/oss-fuzz/getting-started/continuous-integration/</a>)
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)<br>
</p>
<blockquote type="cite"
cite="mid:CAMrKZ9-jJS-LxSgcMT2qFuab-16RPjy4ad58Kdr=+vGhjzso2A@mail.gmail.com">
<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"
moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">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" moz-do-not-send="true">mapserver-dev@lists.osgeo.org</a><br>
>> <a
href="https://lists.osgeo.org/mailman/listinfo/mapserver-dev"
rel="noreferrer" target="_blank" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/mapserver-dev</a><br>
>><br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer"
target="_blank" moz-do-not-send="true">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
<a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>