CVE Content Decisions: Application Guidance for CNAs
Last Modified: November 20, 2014
This document provides guidance to CVE Candidate Numbering Authorities (CNAs) to help them determine how many CVE identifiers to assign to a set of issues.
This guidance only applies to CVE assignment that occurs BEFORE DISCLOSURE. The Primary CNA must be consulted after disclosure and has additional rules that may be followed.
CVE Assignment Might Be Different Than You Expect
Following this guidance is essential. It might not recommend what you expect. People count vulnerabilities differently, which can lead to different methods for how to assign CVE identifiers. However, because there are multiple CNAs, it is important to follow these guidelines in order to guarantee consistency between the CNAs.
This guidance is mostly based on well-established CVE rules called "content decisions." These help CVE to be consistent, even when the amount of details can vary widely across different disclosures, or when knowledge changes across time within a single disclosure. These have emerged over years, but they have proven to be repeatable - if followed properly.
For background information, go to:
CVE Abstraction Content Decisions: Rationale and Application
Index
- INCLUSION Decision Tree - how to determine if an issue should receive a CVE
- ABSTRACTION Decision Tree - how many CVE numbers must be assigned, and how related issues should be grouped together
- Appendix: Handling More Than 2 Issues At Once - when you might be dealing with more than 2 issues
- Appendix: Large-Scale Disclosures - when many products and vendors are affected
- Complex Abstraction Scenarios -
- Final Pre-Disclosure Checklist for CVE -
- Frequently Asked Questions (FAQ)
- Examples
INCLUSION Decision Tree
Use this decision tree to determine if a bug/issue should be assigned a CVE.
The possible conclusions for this decision tree are:
- ASSIGN: - the issue should be assigned a CVE identifier.
- CONSULT: - DO NOT assign a CVE identifier; instead, consult MITRE (issue is complex)
| INC1: | Does exploitation of the issue provide the attacker with extra privileges or information, or cause a denial of service, that the attacker would not already have before they attempt to exploit the issue? |
| |
| INC2: | Has the issue already been reported to a public source that is easily accessible from the Internet? (e.g. Bugtraq, vulnerability database, blog entry, vendor changelog, web bulletin board or newsgroup, open source bug entry, or a product-specific mailing list) |
| |
| INC3: | Is the issue site-specific? Is it only in an online service (software-as-a-service), on a specific web site, or only offered through hosting solutions that are under the full control of the vendor? |
| |
| Relevant content decisions: EX-ONLINE-SVC | |
| INC4: | Does the issue only affect a version that was never made generally available to the vendor's customers? |
|
ABSTRACTION Decision Tree
Use this decision tree to determine how many different CVE identifiers should be assigned to a set of issues. You must address ALL items in the decision tree before making a final decision.
Consider two issues - whether distinct bugs or attack vectors. Assume they satisfy the INCLUSION decision tree. Call them X and Y.
The possible conclusions for this decision tree are:
- SPLIT - assign separate CVE identifiers to X and Y
- MERGE - assign the same CVE identifier to both X and Y (i.e. combine them)
- CONSULT - DO NOT assign a CVE identifier; instead, consult MITRE (issue is complex)
A separate document lists multiple examples of this decision tree. (note: Link disabled pending document updates)
- to do: handling exploits with multiple vuln chains
| * | Are there more than 2 bugs, issues, or attack vectors? | ||||||||||||||||
|
|||||||||||||||||
| ADT1: | (By codebase) Does X affect at least one different product than Y? |
||||||||||||||||
|
|||||||||||||||||
| Relevant content decisions: SF-CODEBASE | |||||||||||||||||
| ADT2: | (By bug type) Are X and Y different bug types? (e.g. buffer overflow, SQL injection, NULL pointer dereference?) See Guidance on Identifying Different Bug Types |
||||||||||||||||
|
|||||||||||||||||
| Relevant content decisions: AB1 | |||||||||||||||||
| ADT3: | (By version) Does X affect a version that Y does not? (e.g. X affects 1.2 and 3.4, but Y only affects 3.4. Consider "1.x" and "1.2" as different.) |
||||||||||||||||
|
|||||||||||||||||
| Relevant content decisions: AB2 | |||||||||||||||||
| ADT4: |
(Address Common SPLIT Assumptions) At this stage, X and Y are the same bug type, affect the same versions, and affect the same products. Do X and Y have any of the following characteristics?
|
||||||||||||||||
|
|||||||||||||||||
| Relevant content decisions: AB3, SF-LOC, SF-EXEC | |||||||||||||||||
| ADT5: |
(By researcher) |
||||||||||||||||
|
|||||||||||||||||
| ADT6: |
(Fall-Through Merge) |
||||||||||||||||
|
Appendix: Handling More Than 2 Issues At Once
When assigning CVEs for groups of more than 2 issues, use the following basic process:
| MULT1: |
|
| MULT2: |
|
| MULT3: |
|
| MULT4: |
|
| MULT5: |
|
Example Table
For example, suppose you have issues V1, V2, V3, V4, and V5, which have different affected versions and bug types. Your table might look something like:
| Bug type | Version | Issues |
|---|---|---|
| XSS | 1.0 | V1 |
| XSS | 1.0 and 2.0 | V2, V3, V4 |
| SQL injection | 2.0 | V5 |
One multi-issue group remains: V2/V3/V4. Apply the ABSTRACTION CDs to that group.
V1 and V5 would be split from this group.
Appendix: Large-Scale Disclosures
When dealing with large-scale problems, use the following item in addition to the regular decision tree.
| LP1: | Is it an implementation problem where many products accidentally make the same mistake? (examples: certificates, FTP user overflows) | ||||
|
|||||
| LP2: | Is it a fundamental problem with the design or protocol? That is, does every implementation have this problem because it must conform to the design/protocol? | ||||
|
Complex Abstraction Scenarios
Vulnerability and Attack Chains
- When dealing with multiple issues that are chained together, a general rule to use is: "if one issue is fixed, then does it automatically fix the second issue?" If so, then the first issue is probably the "root cause," and only one CVE would be needed. But if the second issue could still exist even after the first is fixed, then likely both of them need separate CVEs.
- If bug X creates a condition that introduces bug Y - e.g., an integer overflow that leads to a buffer overflow - then you need to consider whether X, on its own, would be a vulnerability. In the case of an integer overflow leading to a buffer overflow, the integer overflow would not be a problem on its own; it is simply an incorrect calculation.
- Consider issues X and Y. Suppose the attacker can exploit X in order to gain privilege P. Then, using P, the attacker can exploit Y. In this case, the primary question is whether a valid user with privilege P already has the capability to perform Y. For example, consider a web application in which any remote, unauthenticated attacker can call an administrator function that modifies web pages; the attacker then modifies the web page to insert an HTML injection (XSS) attack. Here, an administrator is already allowed to modify HTML; the admin already has the legitimate privileges to insert arbitrary HTML or Javascript code into the page, so to an admin there is no extra benefit to attempting an XSS. As a result, only one CVE would be assigned - to the web application's lack of access control to the admin function - and the XSS would be "resultant" from that.
Variants, Incomplete Fixes, and Regression Errors
Variants. Generally, if an issue X is fixed in one software version, but a new variant, Y, is discovered that affects the new version, these are typically SPLIT. The reason is that X and Y affect different versions.
Regression Errors. Regression errors are generally SPLIT. For the purpose of CVE, a specific issue is called a regression error when:
- the issue appears in a version (e.g., 3.1).
- the issue is fixed in a subsequent version (e.g., 3.2).
- a CVE ID is assigned for this issue.
- at a later time, the exact same issue re-appears in a later version (e.g., 3.4).
In this case, a separate CVE ID would then be assigned.
The rationale is that since there was a fixed version between 3.1 and 3.4, CVE consumers and CVE-compatible tools have likely associated the CVE with only version 3.1, applied patches that are only associated with version 3.1, etc. So, the assignment of a separate CVE ID for the issue in version 3.4 acts as a "signal" that there is a different issue that requires a distinct action.
Later identification of additional affected versions. When an issue is published with one set of versions, and later it is reported that other versions are also affected, this typically will result in a MERGE (with a CVE description update), except for regression errors as outlined previously.
Here are a few common scenarios in which additional versions might be announced at a later time:
- if the vendor is maintaining multiple ranges of versions simultaneously, such as a legacy major version 2.x that is still being actively maintained and a modern major version 3.x, the vendor might announce the vulnerability before all version ranges have been patched. Other affected major versions might have their fixes published days, weeks, or months later. This is not considered a regression error, but instead, a clarification of the set of affected versions for the original bug; as long as the same bug is being patched, a new CVE would not need to be assigned for these additional versions.
- A researcher who does not coordinate closely with a vendor might publicize a vulnerability with incomplete version information, e.g. if they were analyzing an older version of the software. Later, the vendor (or another researcher) might publish that other, later versions are also affected. Typically, no new CVE would be necessary, as long as there are not any apparent fixes in between the original version and the more recently-announced version (which would suggest a regression error); ideally, the CVE description would be updated with the new version information.
Common Assumptions That Frequently Lead to Assignment Errors
- One remote, one local. I have two buffer overflows in the
same product. One is exploitable remotely, and one is
exploitable locally. Should I SPLIT them?
- No (rather, these would stay merged based only on these two criteria). ADT1 would not split - it's the same product. ADT2 would not split - it's the same bug type. ADT3 woud not split - it's the same affected version. However ADT4, explicitly says that the two issues should stay MERGED even if they have a different "access vector."
- Different bugs in different executables. I have two bugs
of the same type in an open source product, such as SQL injection.
There are two separate patches, in parameter X in executable A,
and in parameter Y in executable B. These are clearly
different bugs. Should I SPLIT them?
- No. They are in the same product, so ADT1 would not split. They are the same bug type, SQL injection, so ADT2 would not split. They affect the same version, so ADT3 would not split. Also, ADT4 explicitly says that the issues should stay merged when "X appears in a different DLL, library, program, or application than Y."
- Different Impacts. I have two bugs, both directory
traversal, affecting the same product versions. One allows me to
delete files, and the other allows me to read files. Should I SPLIT
them?
- No. By ADT1, there is no split since the bugs are in the same product. There also is no split for the same bug type (ADT2) and affected versions (ADT3). Finally, ADT4 explicitly recommends merge when "X has a more serious impact than Y."
Frequently Asked Questions (FAQ)
Changing CVE Assignments After Discovering New Information
- I assigned a CVE, but later analysis showed that the issue is not
a vulnerability. The initial bug report was never publicly disclosed.
Can I re-assign the CVE to another issue?
- Probably not, especially if you have shared the CVE ID with any other external party. Consult MITRE.
- I MERGED several issues into a single CVE, but after disclosure,
it became clear that these should have been SPLIT. What should be
done about this?
- Work with MITRE on determining whether a SPLIT should be performed; if so, MITRE will do so.
- I've learned about a duplicate CVE. What should I do? Which CVE
should I use?
- Consult MITRE; only MITRE, as the Primary CNA, can decide which ID to use when a duplicate occurs. (We generally follow the process as documented in https://cve.mitre.org/cve/editorial_policies/duplicates.html).
Limited Disclosure Policy
- I have a disclosure policy where I don't release specific details about vulnerabilities, such as the type of vulnerability. How do I assign CVEs?
- I have a disclosure policy where I don't focus on issues when I don't think they're important enough for my customers. Do I have to assign a CVE to those issues?
Final Pre-Disclosure Checklist for CVE
Shortly before disclosure, follow this checklist for each CVE:
| Share the CVE: | Make sure that you've shared the CVE with all parties who are involved in the disclosure. This reduces the chance of duplicates. |
| Avoid typos: | Make sure that none of your CVE numbers contain typos. One way to do this is to ensure that the CVE web site lists the "RESERVED" string in each of their descriptions. |
| Multiple CVEs assigned: | Ensure that your advisory clearly indicates which CVEs are associated with which issues. |
| New issues discovered: | If new issues were found during the disclosure process, see if you need to SPLIT or MERGE them with the CVEs you already assigned. |
| Early disclosure: | If the issue has already been publicly disclosed, even in a vague way, check with MITRE. Search the CVE or NVD web sites to be sure. |
CVE Content Decision Examples
See this document which lists multiple examples for CD application. (note: Link disabled pending document updates)
Changelog
| Date | Comment |
|---|---|
| September 17, 2008 | Initial creation |
| September 10, 2012 | Added fall-through "Continue to [X]" options to make fall-through more clear. |
| April 19, 2013 | Added and clarified characteristics for ADT4, added additional fall-through options. |
| November 20, 2014 | Improved explanation of "Application Examples" page. Added "Complex Abstraction Scenarios" section. Expanded "Common Assumptions" section. |
</body></html>