Open EvansJonathan opened 7 years ago
kurtseifried
commented
7 years ago Perhaps we should document the different kinds of CVEs, e.g.:
1) implementation vulns (specific code/etc.) 2) protocol level vulns (e.g. CVE-2009-3555) 3) architectural/concept vulns - typically assigned a CWE (cwe.mitre.org), I don't think a CVE is appropriate for these.
dadinolfi
commented
6 years ago The last item here is related to Issue #50.
dadinolfi
commented
6 years ago Suggestion: add paragraph to section C.2 of Appendix C.
CVE IDs can be assigned to vulnerabilities in any code-based entity or standards upon which code-based entities are designed. This can include software, shared codebases, libraries, protocols, standards, hardware, hardware platforms, file formats, or data encodings.
This, along with the split suggested above (creating CNT3 and CNT4), should widen the scope to include what we now intend CVE to be used for. Does it widen the scope too much? Are we missing anything?
chandanbn
commented
6 years ago Suggestion:
Define a specification (=standards upon which code-based entities are designed) as a set of named guidelines for implementing computing logic. For example this covers named protocols (eg., IPv4, TCP, DHCP), file formats (eg., PNG, JPEG, XML, HTML), data encodings (eg., ASN.1, Base64), hardware architectures and standards (eg., x86, x64, SATA 3.3), algorithms (eg., Quicksort, Blowfish, RC4, MD5), standard libraries and APIs (eg., POSIX, JSR5). Two independent implementations of a named specification are likely to be very similar in behavior and functionality.
An implementation is a realization of a specification (which is on paper).
If problem occurs in different named specifications, split and consider each named specification separately.
If there is no named specification in question, split and consider each product separately.
If not sure, split and assign separate CVE IDs.
Specifications and corresponding implementations can differ. Consider all permutations taking one specification, two implementations: If doing something represents a vulnerability, it is marked with a "== VULN".
A1. Specification says to do X (== VULN) Both implementations do X (==VULN)
A2. Specification says to do X One implementation does Y (==VULN), other does Z (==VULN)
B1. Specification is vague or does not say anything Both implementations do X (==VULN)
B2. Specification is vague or does not say anything One implementation does Y (==VULN), other does Z (==VULN)
B can be simply considered as special case of A, where X is "null" or missing.
This boils down to: if there are two implementations a named specification (or a part of it), are they equivalent or different? How does one determine the equivalence?
It should be up to the CNA. Often it is easy to determine based on the description of the problem in the context of a particular named specification. If it can't be determined or there isn't enough information to determine it, then split the issues and assign different CVE IDs.
Suggestion:
CNT 3: Shared code or specifications (Libraries, Protocols, Standards, etc.)
- If the vulnerability is in different specifications,
then split and consider each affected specification.
- If the vulnerability exists due to a particular way of implementing a specification,
assign a single CVE ID.
- Not sure,
assign a CVE ID to each product or implementation.
With the above wording we have eliminated the need for CNAs to analyze code:
If a fragment of vulnerable code is copy pasted into two different products that are used in different computing contexts they get different CVE IDs.
If a fragment of code is copy pasted into two FTP servers, to perform the same function, they get the same CVE ID.
If two independently written fragments of code perform the same function into two different FTP servers, and have the same defect, they get the same CVE ID.
If two unrelated products embed the same library, with the same defect, they use a single CVE ID (as used by the upstream library itself). The library itself can be considered as a named specification.
A CNA does not have to go deeper into investigating if they are based on the same codebase or different codebases.
We have also eliminated the need to analyze standards and protocols to determine if the protocol specification is at fault or the implementation is at fault. We have replaced this with a claim based approach. If a CNA claims that the product implementing FTP server has the exact same problem as in another FTP server, they use the same CVE ID. If not sure, they use a new CVE ID. One can not extend the equivalence claim across different specifications.
GOAL: Make the CNA Rules easier to use CHANGE: Split CNT3 into a rule for codebases and another for standards, libraries, etc. OUTCOME: Increased clarity in the process. WORDING:
GOAL: Make the Counting Rules inline with stakeholders' expectations CHANGE: When there is a way to implement a standard without being vulnerable but the issue is relevant to all implementers, a single ID should be assigned. OUTCOME: Less confusion by consumers and fewer incorrect uses of CVE IDs. WORDING: If there is a way to use the library, protocol, or standard without being vulnerable, assign a single CVE ID.
GOAL: Improve process description CHANGE: Specify whether shared hardware, hardware platforms, file formats, or data encodings are covered. OUTCOME: Less vague or confusing language.