Re: Ramping up Continuous Fuzzing of Virtual Devices in QEMU

[P J P]

+-- 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.

* 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.



Thank you.
--
Prasad J Pandit / Red Hat Product Security Team
8685 545E B54C 486B C6EB 271E E285 8B5A F050 DE8D