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

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



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

Page Last Updated or Reviewed: July 13, 2017