On 201104 1600, P J P wrote:
> +-- On Thu, 22 Oct 2020, Daniel P. Berrangé wrote --+
> | On Thu, Oct 22, 2020 at 12:24:16PM -0400, Alexander Bulekov wrote:
> | > > Once [2] lands upstream, we should see a significant uptick in oss-fuzz
> | > > reports, and I hope that we can develop a process to ensure these bugs
> | > > are properly dealt with. One option we have is to make the reports
> | > > public immediately and send notifications to qemu-devel. This is the
> | > > approach taken by some other projects on oss-fuzz, such as LLVM. Though
> | > > its not on oss-fuzz, bugs found by syzkaller in the kernel, are also
> | > > automatically sent to a public list. The question is:
> | > >
> | > > What approach should we take for dealing with bugs found on oss-fuzz?
> |
> | If we assume that a non-negligible number of fuzz bugs will be exploitable
> | by a malicious guest OS to break out into the host, then I think it is
> | likely undesirable to make them public immediately without at least a basic
> | human triage step to catch possibly serious security issues.
>
> * Maybe the proposed 'qemu-security' list can receive such issue reports. It
> is more close than qemu-devel.
>
> But it also depends on the quantum of traffic oss-fuzz generates. We don't
> want to flood/overwhelm qemu-security list or any other list for that
> matter.
>
If I understand correctly, this is analogous to what happens with
Coverity reports. Access to Coverity is closed (not sure if there is a
process to apply for access). It also seems that there is a push to fix
CID issues prior to new releases. Maybe a similar process can be used for
fuzzing?
> * Human triage is required to know potential impact of an issue before it is
> sent to a public list. It would not be good to send guest-to-host-escape
> type issues directly to a public list.
>
> * Ideally preliminary human triage should be done on the fuzzers' side.
> After it hits an issue, someone should have a look at it before sending an
> email to a list OR maintainer(s).
>
> Ex. TCG issues are generally not considered for CVE. They need not go to a
> security list.
Of all the issues found by the fuzzer, I think there are two major
categories of "false-positives".
* Intentionally-triggerable assertion failures
(e.g. "assert Feature X not supported !")
* Problems only triggerable through CPU (e.g. problems related to
referencing the thread-local "current_cpu" variable.
These should be a minority of all issues for which we can automatically
generate qtest reproducers. As far as I know, OSS-Fuzz isn't fuzzing any
devices unsupported by KVM.
Thanks
-Alex
>
>
>
> Thank you.
> --
> Prasad J Pandit / Red Hat Product Security Team
> 8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D
