[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
RE: An example of hardware/software vulns - GPUs
The most current vulnerability definition would be the following taken
from the CNA Rules Appendix A.
http://cve.mitre.org/cve/cna/CNA_Rules_v1.1.pdf
"A vulnerability in the context of the CVE Program is defined by the
Counting Rules as listed in Appendix C. In general, a vulnerability is
defined as a weakness in the computational logic (e.g., code) found in
software and hardware components that, when exploited, results in a
negative impact to confidentiality, integrity, OR availability.
Mitigation of the vulnerabilities in this context typically involves
coding changes, but could also include specification changes or even
specification deprecations (e.g., removal of affected protocols or
functionality in their entirety)."
If we decide to move forward, it would appear that this definition
covers us for hardware-specific vulnerabilities. Does anyone think
differently or believe that it needs significant changes?
The counting rules themselves would likely need some tweaks as we refer
to code and software in a few places. For example, CNT2.2A refers to
the above definition and would not need to be changed, but CNT2.2B
states "software" specifically. We also would need to change the
Inclusion decisions to either tweak INC3 in regards to
customer-controlled software, or add a new decision that would be
inclusive of hardware.
Regards,
Chris
-----Original Message-----
From: owner-cve-editorial-board-list@lists.mitre.org
[mailto:owner-cve-editorial-board-list@lists.mitre.org] On Behalf Of
Art Manion
Sent: Thursday, July 13, 2017 11:57 AM
To: Millar, Thomas <Thomas.Millar@hq.dhs.gov>; kseifried@redhat.com;
Kent Landfield <bitwatcher@gmail.com>
Cc: Kurt Seifried <kurt@seifried.org>; cve-editorial-board-list
<cve-editorial-board-list@lists.mitre.org>
Subject: Re: An example of hardware/software vulns - GPUs
On 7/13/17 11:24 AM, Millar, Thomas wrote:
> I think my main goal in having a category of hardware vulnerabilities
> covered by CVE would merely be to ensure that manufacturing or design
> issues that cannot be addressed with complete confidence by a
> software
> change are enumerated so that security teams can know they have a
> problem that will require a shipping invoice to properly fix, so to
> speak.
Yes -- if I have to replace hardware/silicon to fully remove a
vulnerability, that should get a CVE ID. Or if instead of replacing I
keep the (strictly) vulnerable hardware but apply microcode/firmware
that mitigates the vulnerability -- CVE ID.
I believe the current counting rules allow this, Kurt, do you disagree?
Do we need to change the counting rules?
- Art