[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Page Last Updated or Reviewed: July 13, 2017