[all] OSS-Fuzz Issue Publication

[Stefan Bodewig <bo...@apache.org>]

Hi (Fabian)

by now we've resolved the first issues detected by ClusterFuzz (and I
forgot to credit it OSS Fuzz in Compress, my bad). What we observed is
that the issues became public automatically once the patch fixing the
issue was merged into master and ClusterFuzz reran the test. In the case
of Compress somewhere around 24 hours after fixing things in master.

So far none of the issues we resolved would be deemed as a security
issue. But now we wonder, what if something indeed was a security issue
that we do not want to become public knowledge before we have cut a
release? Is there a way to prevent a verified and fixed issue from
becoming public automatically?

Here at the ASF we vote on releases, and we vote on the code base in our
default branch (master for most if not all components). Voting takes at
least three days, so the current behavior would mean the issue became
public knowledge a few days before a release fixing it was available.

Can you shed any light on this?

Thanks

        Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [all] OSS-Fuzz Issue Publication

[Fabian Meumertzheim <me...@code-intelligence.com>]

No worries, I'm also not in a rush to change anything, so we can give this
discussion the space and time it deserves. If you want me to weigh in on
any issue you open on GitHub, just @fmeum.

An additional argument in favor of a delayed publication could be that
sometimes completely unrelated upstream changes end up "fixing" a security
issue: The original testcase triggering that issue in OSS-Fuzz no longer
does so. But since the root cause hasn't been fixed, letting the fuzzer run
for a couple of minutes with the now public testcase will reproduce the
original security issue. Of course, someone who goes to those lengths could
just run the fuzzers themselves, so the actual impact of that situation is
not clear.


On Sun, May 9, 2021 at 8:54 PM Stefan Bodewig <bo...@apache.org> wrote:

> Many thanks Fabian
>
> and sorry for the delay - unfortunately I'm not really able to free up
> as much time as necessary for any OSS stuff right now
>
> On 2021-05-03, Fabian Meumertzheim wrote:
>
> > The behavior you are observing has only become the standard somewhat
> > recently [1], which is also why I had decided to point it out before we
> > performed the integration [2].
>
> > [1] https://github.com/google/oss-fuzz/issues/5255
>
> I must have overlooked that back then - or just didn't understand what
> it meant. One key is the phrase "after a patch is released" which also
> is used in [1] which means a completely different thing to ASF
> communities than to the person opening the issue above. Nobody around
> here would argue against disclosing details of a vulnerability after a
> new release containing the fix is available.
>
> The best we can do probably is pointing out that the new policy is
> incompatible with the ASF security policy - point 14 in
>
> https://www.apache.org/security/committers.html#vulnerability-handling
>
> without trying to argue who is right. Going from there we will see
> whether there is an option for ASF projects to continue using OSS Fuzz
> or not. Unfortunately I believe this discussion must be driven by
> somebody with a predictable and sufficiently large slice of time for
> this, which I will not be for at least the next week, likely longer.
>
> Unless anybody else jumps in I'll take it on myself once I believe to be
> available. Fortunately so far no issues have shown up that would force
> ou hand - and even if something came up I'm sure we could figure out
> some sort of singular exemption.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Re: [all] OSS-Fuzz Issue Publication

[Stefan Bodewig <bo...@apache.org>]

Many thanks Fabian

and sorry for the delay - unfortunately I'm not really able to free up
as much time as necessary for any OSS stuff right now

On 2021-05-03, Fabian Meumertzheim wrote:

> The behavior you are observing has only become the standard somewhat
> recently [1], which is also why I had decided to point it out before we
> performed the integration [2].

> [1] https://github.com/google/oss-fuzz/issues/5255

I must have overlooked that back then - or just didn't understand what
it meant. One key is the phrase "after a patch is released" which also
is used in [1] which means a completely different thing to ASF
communities than to the person opening the issue above. Nobody around
here would argue against disclosing details of a vulnerability after a
new release containing the fix is available.

The best we can do probably is pointing out that the new policy is
incompatible with the ASF security policy - point 14 in

https://www.apache.org/security/committers.html#vulnerability-handling

without trying to argue who is right. Going from there we will see
whether there is an option for ASF projects to continue using OSS Fuzz
or not. Unfortunately I believe this discussion must be driven by
somebody with a predictable and sufficiently large slice of time for
this, which I will not be for at least the next week, likely longer.

Unless anybody else jumps in I'll take it on myself once I believe to be
available. Fortunately so far no issues have shown up that would force
ou hand - and even if something came up I'm sure we could figure out
some sort of singular exemption.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org

Re: [all] OSS-Fuzz Issue Publication

[Fabian Meumertzheim <me...@code-intelligence.com>]

Hi,

The behavior you are observing has only become the standard somewhat
recently [1], which is also why I had decided to point it out before we
performed the integration [2].

Let me first confirm the facts: It is correct that OSS-Fuzz will
automatically open the Monorail bugs to the public roughly a day after a
patch has been verified upstream. The bug includes the crashing input, a
truncated stack trace and all discussions that have been submitted on it.
The detailed OSS-Fuzz report, including the full stack trace and minimized
crashing input becomes semi-public: it can be accessed by anyone who is a
primary_contact/auto_cc for *any* project hosted on OSS-Fuzz.

The rationale for the new policy is explained briefly in [1]. Based on a
conversation I had with an OSS-Fuzz maintainer, I would paraphrase this as
follows: An upstream patch, no matter how innocuous the commit message may
be, always has the potential to give away the fact that it exists to fix a
security issue. This is especially true if a malicious third party has any
interest in finding security issues in a particular open-source project.
However, the easiest and certainly most cost-effective way to find such
issues would not be to monitor and audit upstream patches, but rather to
dedicate more CPU time to running the project's own fuzzers than OSS-Fuzz.
While running OSS-Fuzz for all projects is certainly costing Google a lot
of money, outperforming them on a single project is not expensive. Hence,
bugs found by OSS-Fuzz should be assumed to be already known to anybody
with a particular interest in breaking a particular library. Since test
cases produced by OSS-Fuzz are not complete exploits (they are inputs to
libraries, not applications), they aren't going to be useful for "drive-by
script kiddies" or the likes. From that point of view, where dedicated
third parties already have the opportunity to find bugs before the
maintainers, this becomes more about keeping the user base in the know
about security issues in the libraries they are using, e.g. via a project
like OSV [3] as mentioned in [1].

That said, I fully understand your concerns and think that it might be
possible to accommodate both your usual patch release workflow as well as
the general OSS-Fuzz policies. For example, it could be reasonable to keep
the crashing inputs non-public for an extended period of time (e.g. the 30
days bugs originally remained private for after the fix), while the
conceptual information about the bug (i.e., it's Monorail entry on [4])
becomes public immediately. Can you think of a "middle ground" like this
that would work for Apache?

Given that OSS-Fuzz has very responsive maintainers and is fundamentally
open-source, I would suggest to open an issue on the repository where
follow-up discussions are accessible to a wider audience. It may be the
case that the change made in [1] has not received the publicity it deserves
yet and I'm sure the OSS-Fuzz maintainers would welcome your feedback on
the new policy. If you prefer it this way, I could also create the issue
myself tomorrow.

Fabian

[1] https://github.com/google/oss-fuzz/issues/5255
[2]
https://mail-archives.apache.org/mod_mbox/commons-dev/202104.mbox/%3CCAMD8YMQ3ODf%3DTn8YAjsUkmym2wZ3TogR8uMy%2Bhb82asL6YEQhQ%40mail.gmail.com%3E
[3] https://github.com/google/osv
[4] https://bugs.chromium.org/p/oss-fuzz/issues/list

On Mon, May 3, 2021 at 2:59 PM Stefan Bodewig <bo...@apache.org> wrote:

> Hi (Fabian)
>
> by now we've resolved the first issues detected by ClusterFuzz (and I
> forgot to credit it OSS Fuzz in Compress, my bad). What we observed is
> that the issues became public automatically once the patch fixing the
> issue was merged into master and ClusterFuzz reran the test. In the case
> of Compress somewhere around 24 hours after fixing things in master.
>
> So far none of the issues we resolved would be deemed as a security
> issue. But now we wonder, what if something indeed was a security issue
> that we do not want to become public knowledge before we have cut a
> release? Is there a way to prevent a verified and fixed issue from
> becoming public automatically?
>
> Here at the ASF we vote on releases, and we vote on the code base in our
> default branch (master for most if not all components). Voting takes at
> least three days, so the current behavior would mean the issue became
> public knowledge a few days before a release fixing it was available.
>
> Can you shed any light on this?
>
> Thanks
>
>         Stefan
>

Re: [all] OSS-Fuzz Issue Publication

[Gary Gregory <ga...@gmail.com>]

Voting takes three days or less if we decide we need an emergency release
for a security issue for example. In reality, it can take weeks for a
release manager to volunteer for a given component, review code, PRs,
Jiras, an so on, before going through all the hoops to create a release
candidate and then the release. So, the buffer of time should never be
automatic. The issue should be made public only after a release in the case
of security issues.

Gary


On Mon, May 3, 2021, 08:59 Stefan Bodewig <bo...@apache.org> wrote:

> Hi (Fabian)
>
> by now we've resolved the first issues detected by ClusterFuzz (and I
> forgot to credit it OSS Fuzz in Compress, my bad). What we observed is
> that the issues became public automatically once the patch fixing the
> issue was merged into master and ClusterFuzz reran the test. In the case
> of Compress somewhere around 24 hours after fixing things in master.
>
> So far none of the issues we resolved would be deemed as a security
> issue. But now we wonder, what if something indeed was a security issue
> that we do not want to become public knowledge before we have cut a
> release? Is there a way to prevent a verified and fixed issue from
> becoming public automatically?
>
> Here at the ASF we vote on releases, and we vote on the code base in our
> default branch (master for most if not all components). Voting takes at
> least three days, so the current behavior would mean the issue became
> public knowledge a few days before a release fixing it was available.
>
> Can you shed any light on this?
>
> Thanks
>
>         Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>