[dpdk-dev] [oss-security] DPDK security advisory for multiple vhost crypto issues

[Mauro Matteo Cascella]

On Mon, Jan 4, 2021 at 12:29 PM Ferruh Yigit <ferruh.yigit at intel.com> wrote:
>
> On 1/4/2021 8:28 AM, Mauro Matteo Cascella wrote:
> > Hello,
> >
> > Is there any particular reason for the Scope metric to be Unchanged
> > (S:U) for CVE-2020-14377 and CVE-2020-14378?
> >
>
> removed dpdk-announce mail list
>
> Hi Mauro,
>
> CVE-2020-14377, the memory over read is in the scope of the same application,
> that is the reason of the unchanged scope. There is another CVE below that can
> use this information to figure out where to overwrite for remote execution which
> has scope set as 'Changed'.
>
> CVE-2020-14378, can cause loop taken longer time and delays the service, since
> it is eating the core cycles, if there is something else using that specific
> core technically it may delay it too, but DPDK mostly uses all core for itself
> and since mainly the vhost crypto service is affected, scope selected as Unchanged.
>
> Is there a concern on the selected scope metric?
>
> Thanks.
>

Thank you for the timely reply. With regard to CVE-2020-14377, the
Scope metric was rated differently by NIST [1] hence my initial
question.

[1] https://nvd.nist.gov/vuln/detail/CVE-2020-14377

> > On Mon, Sep 28, 2020 at 5:43 PM Ferruh Yigit <ferruh.yigit at intel.com> wrote:
> >>
> >> A set of vulnerabilities are fixed in DPDK:
> >> - CVE-2020-14374
> >> - CVE-2020-14375
> >> - CVE-2020-14376
> >> - CVE-2020-14377
> >> - CVE-2020-14378
> >>
> >> Some downstream stakeholders were warned in advance in order to coordinate the
> >> release of fixes and reduce the vulnerability window.
> >>
> >> Problem:
> >> A malicious guest can harm the host using vhost crypto, this includes
> >> executing code in host (VM Escape), reading host application memory
> >> space to guest and causing partially denial of service in the host.
> >>

>From the problem statement above I assume all these CVEs lead to some
kind of guest-to-host compromise, which usually implies a Scope change
(or at least, this holds true for QEMU flaws). Therefore I was
wondering what's the reason behind the different evaluation of the
Scope metric between CVE-2020-14377 and the others.

Regards.
--
Mauro Matteo Cascella
Red Hat Product Security
PGP-Key ID: BB3410B0