RE: An example of hardware/software vulns - GPUs

["Millar, Thomas" <Thomas.Millar@hq.dhs.gov>]

In that case we would want to add a constraint such as:
"Security exposures created by the physical failure of a hardware 
component are not within the scope of CVE."

-----Original Message-----
From: Pascal Meunier [mailto:pmeunier@cerias.purdue.edu] 
Sent: Thursday, July 13, 2017 11:04 AM
To: Millar, Thomas <Thomas.Millar@hq.dhs.gov>; Kent Landfield 
<bitwatcher@gmail.com>
Cc: Art Manion <amanion@cert.org>; 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

A CVE entry that would have nothing to do with computer science or the 
logic embedded in the connection of hardware gates, would be dissonant.
     As I recall, the original implicit purpose and scope of the CVE 
was vulnerabilities that can be understood within the field of computer 
science.

I'm sure malfunctions due to a device not meeting its temperature 
ratings or marketing claims of water or shock resistance can cause 
vulnerabilities of some kind, but I suggest somebody else track them. 
Focus is important to doing something well, let's not take on too much.
   I believe the CVE effort should focus on vulnerabilities whose fixes 
belong within the field of computer science, not on those fixed by 
changing some mechanical housing properties or semiconductor 
manufacturing process.

Pascal

On Thu, 2017-07-13 at 14:17 +0000, Millar, Thomas wrote:
> So the answer turns out to be that if we want greater coverage of 
> true 
> hardware vulnerabilities, we need to figure out how to include 
> exactly 
> what needs to be covered in the Counting Rules definitions and then 
> update the documentation. I think Kurt’s point about tolerances 
> inherited from product standards and/or marketing pronouncements is a 
> reasonable starting point.
> 
> From: Kent Landfield [mailto:bitwatcher@gmail.com]
> Sent: Thursday, July 13, 2017 9:47 AM
> To: Millar, Thomas <Thomas.Millar@hq.dhs.gov>
> Cc: Art Manion <amanion@cert.org>; 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
> 
> 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).”
> A vulnerability is a flaw or design oversight in software that could 
> be used by an attacker to gain unintended access to a system or 
> network. CVE considers a flaw a vulnerability if it allows an 
> attacker 
> to use it to violate a reasonable security policy for that system 
> (this excludes entirely “open” security policies in which all users 
> are trusted, or where there is no consideration of risk to the 
> system).
> 
> A vulnerability in the context of the CVE program is indicated by 
> code 
> that can be exploited, resulting in a negative impact to 
> confidentiality, integrity, OR availability, and that requires a 
> coding change, specification change, or specification deprecation to 
> mitigate or address.
> 
> 
> Dropping an iPhone would not be covered by the multiple versions of 
> the definition of a vulnerability we are using.
> 
> 
> Maybe we want one definition ....
> 
> Kent Landfield
> +1.817.637.8026
> 
> On Jul 13, 2017, at 9:08 AM, Millar, Thomas <Thomas.Millar@hq.dhs.gov 
> <mailto:Thomas.Millar@hq.dhs.gov>> wrote:
> What is the scope constraint for hardware vulnerabilities? Dropping 
> iOS devices in most fluids leads to a DoS condition.
> 
> 
> 
> Tom Millar, US-CERT
> 
> Sent from +1-202-631-1915
> https://www.us-cert.gov
> 
> ________________________________
> 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 1:58:22 PM
> To: Kurt Seifried; cve-editorial-board-list
> Subject: Re: An example of hardware/software vulns - GPUs On 
> 2017-07-10 00:04, Kurt Seifried wrote:
> > https://www.aimlab.org/haochen/papers/npc16-overflow.pdf
> > 
> > I really think CVE needs to consider more/better hardware coverage.
> 
> I only skimmed the first few pages, but got the impression that paper 
> says "GPU architecture is different that modern CPUs, especially 
> around memory layout/protection" and it isn't immediately clear to me 
> where responsibility for any vulnerability lies.  Is it simply not 
> possible to write memory-corruption-proof code for GPUs?
> 
> Regardless, I have no problem with issuing CVE IDs for hardware 
> vulnerabilities.  I'm just claiming that they are rare, and usually 
> involve low-level software.
> 
>  - Art