Allow assignments to vulnerabilities in hardware

[EvansJonathan]

GOAL: Cover vulnerabilities people care about
CHANGE: Allow assignments to vulnerabilities in hardware.
OUTCOME: Discussion about and fixing vulnerabilities will be easier

[kurtseifried]

Simple: add more CNA's, specific ones (e.g. vendors) and classes (e.g. "VPN software"), also allow third parties to be a CNA for a given project/entity (something the DWF is in the process of doing), it's simple, if someone wants to be a CNA for something, then by definition they care, let them do it.

[dadinolfi]

The current definition for "vulnerability" in Appendix A explicitly includes hardware. We can beef this up by changing the first sentence of 1.0 to read:

The Common Vulnerabilities and Exposures (CVE) Program’s primary purpose is to uniquely identify vulnerabilities and to associate specific versions of code bases (e.g., software, shared libraries, firmware, and microcode in hardware) to those vulnerabilities.

[chandanbn]

There can be hardware vulnerabilities with no fault in the code, or no code involved.
'Row Hammer' is one example.

It may be possible to change code to remediate the vulnerability, but not in all cases.

Other example is when Reed switches and Hall effect sensors are used to make security or logic decisions as in door open sensors. An attacker can circumvent them by holding a strong magnet near them. PIR motion sensors can be circumvented by mylar blankets.

Widespread use of sensors in IoT, medical, automotive space makes this more likely there may be CNAs who may care about identifying such issues with CVE IDs.

[dadinolfi]

In the Row Hammer case, CVE IDs were assigned. Row Hammer is an exploit, though, not a vulnerability itself. The vulnerability was in the design, not taking that kind of attack into account.

For your sensors and locks example, I would argue those are design limitations, not vulnerabilities. These aren't logical attacks affecting the logic of the system. They are attacks that exploit the basic nature of physical objects. We need to draw the line on CVE assignment somewhere, otherwise we would need to assign CVE IDs to every device that can't survive (and perform as designed when experiencing) a flood, fire, plague of frogs, etc.

I think it would be useful to include hardware vendors in these discussions as we bring them into the program. Their assumptions and risk models may be different from those we have traditionally used for CVE, and without understanding those, we may not know the best way to answer if these meat-space attacks should get CVE IDs.

If we leave the language as it is, I think we can invite the community to chime in on their thoughts how best to word this going forward and revise again after we've had that input.

[chandanbn]

I agree that limitations and risks that are known perhaps are not worth assigning CVE ids. That extends to software as well. Take Telnet transmitting passwords in the clear as an example.

The line I would draw is vendor's security assurance: does the vendor provide an assurance about the security policies in the product?

SSH transmitting passwords in the clear would be a CVE worthy vulnerability since the vendor provides an assurance that they will not be, but Telnet has no such assurance.

Consider keyboards emitting distinct radio waves on each key stroke, allowing a physically close attacker to capture keystrokes - by definition that is an information leak vulnerability. It has a CVSS score of 2.1. If a hardware vendor sold you a keyboard claiming it does not leak keystrokes through radio waves, but it does, then that would be worth a CVE assignment. Such vulnerabilities are fixable - by making the keyboard case a Faraday cage.

On sensors and IoTs, there is logic or code involved that trusts certain input from sensors that can not be trusted and makes security decisions (ring the alarm or not). I see it no differently from software bugs that take untrusted input and choke.