Skip to content

Distinguish physical access from software/firmware weaknesses that are discovered by opening the physical enclosure #38

@GeorgesBolssens-Toreon

Description

@GeorgesBolssens-Toreon

Rule 4.1.5.2 is being interpreted in different ways by two CNAs, leading to a discrepancy in understanding whether the rule creates a way out of assigning a CVE subsequent to physical attacks.

The crux: "If an underlying vulnerability is discovered after opening the case, is it disqualified from being assigned a CVE?"

We argue no, the CNA we are reporting to says yes.

Current text (v4.0):

4.1.5.2 Physical theft, damage, or destruction are not by themselves cybersecurity Vulnerabilities. CNAs SHOULD NOT determine physical access to a processor, memory, bus, or other hardware component to be a cybersecurity Vulnerability.

The "by themselves" qualifier in sentence 1 is load-bearing; its absence in sentence 2 makes the second sentence read as a flat exclusion of any weakness reachable via an internal interface, which collapses the vector/weakness distinction that CVSS and CWE otherwise preserve.

Proposed text:

4.1.5.2 Physical theft, damage, destruction, or the act of physically accessing a processor, memory, bus, or other internal hardware component (e.g., by opening an enclosure and attaching probes to test points) are not by themselves cybersecurity Vulnerabilities.

4.1.5.2.1 A software or firmware weakness is not excluded from CVE eligibility solely because the reporter's demonstration involved a physical interface. Such weaknesses are evaluated under 4.1.5 and 4.1.5.1 on the basis of the weakness itself (e.g., CWE-312, CWE-306, CWE-798, CWE-327).

4.1.5.2.2 A physical interface that is externally exposed and user-facing (e.g., a labeled serial or USB port intended for user operation) that grants privileged access without authentication SHOULD be determined to be a Vulnerability under 4.1.5.1.

Happy to iterate on wording.

Metadata

Metadata

Assignees

No one assigned

    Labels

    4.3.0Candidates for 4.3.0.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions