Re: Ramping up Continuous Fuzzing of Virtual Devices in QEMU

[Alexander Bulekov]

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