Re: An example of hardware/software vulns - GPUs

[Kent Landfield <bitwatcher@gmail.com>]

Agreed.

Kent Landfield

+1.817.637.8026 

On Jul 13, 2017, at 10:17 AM, Millar, Thomas <Thomas.Millar@hq.dhs.gov> 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> 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 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