<div dir="ltr">The full report is worrisome with a web application when thinking about a worst case scenario where a security issue is found. I mean you can patch and release new version(s) with a general disclosure but publishing the exploit details (the reproducer) seems like a bad idea to me in some cases. It seems to take awhile for new MapServer versions to take hold so someone not paying attention could be screwed. <div><br></div><div>That said, it's potentially super valuable testing...</div><div><br></div><div>--Steve</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 13, 2021 at 7:26 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div>
    Steve,
    <blockquote type="cite">
      <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 href="https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16443" target="_blank">https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=16443</a><br>
    </p>
    <blockquote type="cite">
      <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 href="https://google.github.io/oss-fuzz/getting-started/continuous-integration/" target="_blank">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">
      <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" target="_blank">even.rouault@spatialys.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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>
    </blockquote>
    <pre cols="72">-- 
<a href="http://www.spatialys.com" target="_blank">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
  </div>

</blockquote></div>