1. CNA Rules 2.0: Counting Rules
CVE Team

2. Overview Explain what Counting Rules are and why they exist
Review each rule
Explain the rules and provide guidance where the rules are undefined
Go over each of the rules

3. Definition and Purpose
The CVE Counting Rules define how to assign a CVE ID to a vulnerability
The Counting Rules must achieve CVE’s purpose and provide the intended values:
Purpose: To uniquely identify and name publicly disclosed vulnerabilities pertaining to specific versions of software or codebases
Value: Stakeholders have confidence that they can refer to a CVE Identifier (ID) and know they are talking about a specific, unique vulnerability regardless of the tool or forum being used

4. Is there an established method to count vulnerabilities?

5. Definitions of Vulnerability
Many different organizations have their own definition of a vulnerability:
NIST: A weakness in the computational logic found in products or devices that could be exploited by a threat source [NISTIR 8138]
ISACA: A weakness in the design, implementation, operation or internal control of a process that could expose the system to adverse threats from threat events [1]
CERT: A software defect that allows an attacker to violate an explicit (or implicit) security policy to achieve some impact (or consequence). [2]
OWASP: A vulnerability is a hole or a weakness in the application, which can be a design flaw or an implementation bug, that allows an attacker to cause harm to the stakeholders of an application. Stakeholders include the application owner, application users, and other entities that rely on the application. [3]
Microsoft: A security vulnerability is a weakness in a product that could allow an attacker to compromise the integrity, availability, or confidentiality of that product. [4]
HackerOne: A software bug that would allow an attacker to perform an action in violation of an expressed security policy. A bug that enables escalated access or privilege is a vulnerability. Design flaws and failures to adhere to security best practices may qualify as vulnerabilities. Weaknesses exploited by viruses, malicious code, and social engineering are not considered vulnerabilities unless the Security Team says otherwise in the program's policy. [5]
Everyone’s definition of a vulnerability is different. While there is often overlap they vary widely in what they cover.
[1]
[2]
[3]
[4]
[5]

6. There will Always be Edge Cases
A collision for an MD5 hash can be found in a reasonable amount of time. Does this mean that every product using MD5 should have a CVE ID assigned to it?
Opinion 1: Yes, MD5 is vulnerable, therefore the products using MD5 are vulnerable.
Opinion 2: No, not all products use MD5 for security reasons.
Opinion 3: No, a single CVE ID should be issued for MD5. All other implementation should use that ID.
Default Credentials
Opinion 1: Yes, standard security practice says that default credentials are bad.
Opinion 2: No, this is a configuration issue. Standard security practice is to change default credentials upon installation.
Cloudbleed: A vulnerability in Cloudflare’s code leaks sensitive information from the websites that use its service
No: Only one vendor had to make a change.
Yes: Many people had to take cleanup actions in response to this vulnerability.
Even when a definition is shared, the imprecision of language causes many edge cases.

7. Methods of Separating Vulnerabilities
SQL injection in version 1.x through login.php and order.php.
SQL injection in version 2.x through admin.php.
XSS in version 2.x through login.php and search.php.
By Vulnerability Type
And Affected Versions
SQL injection in login.php
SQL injection in admin.php
By Vulnerability Type
And Affected Component
SQL injection in order.php
XSS in login.php
XSS in search.php
Multiple SQL injections in 1.x and 2.x
XSS in 2.x
By Vulnerability Type
SQL injection and XSS in 1.x and 2.x
By Patch
Even when you agree that there is a vulnerability. You can’t always get agreement on how many there are.
All of these methods have been
used by vulnerability databases

8. CVE Must Create its Own Standard
To achieve CVE’s purpose, the rules must:
Define what is to be counted (i.e. vulnerabilities)
Ensure only unique vulnerabilities are assigned IDs
Duplicate assignments shouldn’t be made
Requires a method of distinguishing between vulnerabilities
Ensure the IDs can be used for cross-communication
Some additional, secondary goals the Rules are
Be easy to use by a large, diverse set of CNAs
Ensure consistent results when given the same information

9. Counting Process Summary
Start by breaking the report into individual bugs
Determine if the bugs result in vulnerabilities
For the bugs that don’t, determine if a combination of the bugs results in a vulnerability
Then determine which set of products are affected
Now that you have identified the affected product(s), you can decide if the vulnerability is in your scope or someone else’s
Product is being used broadly here. It includes libraries, protocols, and standards
You then determine if there is value to the community in assigning an ID
The information about the vulnerability must be public (If no one knows which vulnerability the ID is assigned to, it doesn’t help them)
The vulnerability is in software they have some control
They have to be concerned about the security of the product
Finally, determine if a CVE ID has already been assigned to the vulnerability

10. The Decision Process Varies in Practice
The rules are written as a step-by-step process
In practice the various steps are interrelated and the order often changes
For example, “INC1: In Scope of Authority” is the fourth decision in the process
But if a report comes in for a vulnerability in a product that is outside the CNA’s scope, it can use INC1 to reject it immediately.
For the official rules, INC1 is after CNT3 because you cannot be certain the product is in the CNA’s scope until the codebase analysis has been performed.

11. Counting Rules

12. Counting Rules Structure
Counting Decisions
Number of vulnerabilities
Inclusion Decision
Whether or not a CVE ID should be assigned
Who should do the assignment

13. Counting Decisions Overview
CNT1
Independently Fixable
Divide the bugs into independently fixable groups
CNT2
Do the bugs result in a vulnerability?
CNT2.1: Does the vendor acknowledge the vulnerability?
CNT2.2A: Claim-based model
CNT2.2B: Policy-based model
CNT3
Merge vulnerabilities if they are the result of a shared codebase

14. CNT1: Split by Independently Fixable Groups of Bugs
Independently Fixable: For each reported bug, determine if it can be fixed independently of the other bugs (i.e., a code fix can be created to fix only the bug in question).
A common indicator of independently fixable would be that the vulnerability affects a different version of the product than the other reported vulnerabilities. Note that this does not mean the bugs are fixed independently, but that the vendor can choose to fix the bugs independently.
Purpose
Set the baseline for counting
Have everyone assign IDs at the same level
Assignments at different level can result in overlapping/duplicate assignments
Process Steps
Identify the individual bugs
For each bug, determine if it can be fixed without fixing another bug
If a bug cannot be fixed without fixing one or more other bugs, group those bugs together
If it is unclear whether or not the bugs are independently fixable, merge them together
Fix formatting

15. CNT1: Identify Individual Bugs
Rejected Definitions
As with vulnerabilities, there is no shared definition of bug
Tried to provide simple rules
Had definition problems
Often resulted in unacceptable outcomes
Could not come to an agreement
Left to the CNA’s judgement
The models from CNT2 can help make the judgement
Claim-based: Separate into groups of independently fixable claims
MITRE uses this model
Policy-based: Separate into groups of independently fixable policy violations

16. CNT1: Determine if Bugs are Independently Fixable
What matters for CNT1 is that the bugs COULD be fixed independently
It does not matter if a single change was used to fix multiple independently fixable vulnerabilities, e.g. we are not counting patches
It does not matter if multiple code changes were used to fix a single vulnerability
The results are highly dependent on the information available
Access to source code and code pathing help significantly
One reason the CNA most familiar with the product should make the assignments (INC1)
There will often not be enough information to make a perfect determination
If unsure, merge the bugs into a single group

17. CNT1 Example 1
How many vulnerabilities are there in the following report?
Buffer overflow in Product A by passing a long string to the:
Show script command
Clear script command
Show archive command
Clear archive command
Show log command
Clear log command
Some would consider this six vulnerabilities, while other would consider it one vulnerability, and others may fall in between

18. CNT1 Example 1 Continued
There are three different code blocks below show different ways the example could be implemented.
Each red strcpy call represents a place in the code where a buffer overflow can happen.
How many IDs should be assigned for each?
if (strcmp(cmd, "show") == 0) {
if (strcmp(arg1, "script") == 0) {
strcpy(str, long_input);
show_script(str); }
elsif (strcmp(arg1, "archive") == 0) {
show_archive(str); }
elsif (strcmp(arg1, "log") == 0) {
show_log(str); } }
elsif (strcmp(cmd, "clear") == 0) {
Scenario 3:
Scenario 1:
if (strcmp(cmd, "show") == 0) {
strcpy(str, long_input);
process_show_command(str); }
elsif (strcmp(cmd, "clear") == 0) {
process_clear_command(str); }
strcpy(arg, long_input);
if (strcmp(cmd, "show") == 0) {
process_show_command(arg); }
elsif (strcmp(cmd, "clear") == 0) {
Scenario 2:

19. In the code excerpt for Scenario 1:
There are two problematic strcpy calls
A range check can be placed before each to fix them
The range check would fix the strcpy just below it, without fixing the issues with the other strcpy calls
Two CVE IDs should be assigned
In the code excerpt for Scenario 2:
There is only one call strcpy
The check must be placed before the strcpy call
There is no way to fix one of the vectors without fixing the others
A single CVE ID should be assigned
In the code excerpt for Scenario 3:
There are six strcpy calls
Each results in the str buffer being overflown
Six CVE IDs should be assigned
Note that the range check could be placed before the first if statement in each case, but this is irrelevant for determining if the bugs are independently fixable

20. CNT1: Group Bugs that Are Not Independently Fixable
When would a bug not be independently fixable?
Chains – multiple bugs strung together are required to result in a vulnerability (e.g., an integer overflow that leads to a buffer overflow)
Composites – multiple bugs combine to result in a single vulnerability (e.g., symbolic link attacks require insecure permissions, predictable file names, and a race condition)
In both cases, if one bug is fixed, the other bugs do not result in a vulnerability by themselves

21. Chains: Not Independently Fixable
Use of Signed Integers for Always-Positive Operations
Insufficient Memory Allocation
Incorrect
Range
Check
Integer
Overflow
Heap
Overflow
height = ; width =
if (height > ||
width > 64000) {
error("too big!"); }
size = height * width;
buf = malloc(size);
memmove(buf, InputBuf, SZ); A B C D
Assumption: The range check will prevent an overflow from occurring.
Note that there is an independently fixable vulnerability in the code when you set height and/or width to 0.

22. Chains: Possible FixesD
Use of Signed Integers for Always-Positive Operations
Insufficient Memory Allocation
Incorrect
Range
Check
Integer
Overflow
Heap
Overflow
Fix 1: Correct A (Incorrect Range Check)
Fixes the integer overflow, which prevents the insufficient memory allocation and heap overflow
A fix for the integer overflow will always fix the heap overflow
Fix 2: Check the for integer overflow before allocating memory
Fixes C (Insufficient Memory Allocation), which prevents the heap overflow.
With C and D fixed, A and B no longer have a security impact, and therefore are no longer vulnerabilities
A fix for the heap overflow will always fix the integer overflow vulnerability
The integer overflow and heap overflow are not independently fixable

23. CNT2: Is it a Vulnerability?
Purpose
Limit CVE’s scope to vulnerabilities
No generally agreed upon definition of vulnerability
CNT2 provides some sub-decisions to help decide if something is a vulnerability
CNT2.1: The vendor says the vulnerability does bad things (vendor decides)
CNT2.2A: The reporter says the vulnerability does bad things (researcher decides)
CNT2.2B: The CNA decides a security policy violation occurs (CNA decides)
Vendor CNAs will most often use CNT2.1
However, if someone disputes the CNA’s decision, they will need to use CNT2.2B to justify their decision
I used “bad things” intentionally to point out that the impact is a very loose requirement.

24. CNT2.1: Vendor Acknowledgement
Vendor acknowledgment: Does the affected vendor acknowledge the bug as a vulnerability and does it also acknowledge a negative impact on security?
Examples of negative impact could include; code execution, providing the attacker with extra privileges or information, causing a denial of service, etc.
Process
Determine product vendor
Determine if the vulnerability is acknowledged
Determine if the acknowledgement says there is a negative impact

25. CNT2.1 Process Determine product vendor
Vendors who bundle the affected product on their own can be considered vendors for this decision, but CNT3 and INC1 may have an effect on the scope the vulnerability
If the product was abandoned and supported by someone else, it is best to use CNT2.2
Determine if the vulnerability is acknowledged
The vendor has to recognize the bug and say that it has a security impact
Simply saying that the bug is fixed is not considered an acknowledgement of the vulnerability
If unsure, use CNT2.2.
Determine if the acknowledgement says there is a negative impact
Let the vendor decide what a negative impact is for the product

26. CNT2.2: Vulnerability Models
CNT2.2B
Security model-based: Does the vulnerability report provide evidence of a mistake or design oversight in software that violates the security policy of the system?
CNT2.2A
Claim-based: Does the vulnerability report provide a demonstrated negative impact for the bug?
CNT2.2 provides two options for CNAs to choose from
CNT2.2A: Claim-based – The bug(s) are considered a vulnerability because the requester says they have a negative impact
CNT2.2B Policy-based – The CNA determines the bug(s) result in a vulnerability because security policies are violated
CNT2.2A Process
Decide if the requester defined a negative impact
CNT2.2B Process
Identify the security policies for the product
Determine if any of the security policies were violated

27. CNT2.2: Security Model vs. Vulnerability Claim
CNT2.2B
Security model-based: Does the vulnerability report provide evidence of a mistake or design oversight in software that violates the security policy of the system?
CNT2.2A
Claim-based: Does the vulnerability report provide a demonstrated negative impact for the bug?
Pros
Higher accuracy
Tends to be incontrovertible
More consistent assignments
Cons
Users and vendors do not always agree on security policy
Often many of the policies are not documented
Hard to know from the outside
MITRE used this decision for the old rules
Pros
Easy
Fast
Cons
Inherently trusts researchers
Could result in wide variations in abstraction
Requires distinct claims
Opinions differ on identification of negative impact
MITRE is using this decision for the new rules

28. CNT2.2: Example Vulnerability Claim
Stored XSS vulnerability in the admin page of a WordPress module allows unauthenticated attackers to obtain cookies
Security Model
Vulnerability Claim
Regular users should not have access to admin pages except wp- admin/admin-ajax.php
Can administrators inject arbitrary script into pages?
Only if they have the unfiltered_html permission, which they have by default except when WordPress is installed in Multisite mode
Assign one or two CVE IDs, depending on the answers to the questions
The reporter claims there is a XSS vulnerability (improper/no sanitation)
The reporter says it can be used to obtain cookies
Assign a single CVE ID

29. CNT3: Shared Codebase, Library, Protocol, etc.
Shared Codebase, Library, Protocol: Does the vulnerability affect a shared codebase, library, or protocol implementation issue? In addition, consultation with the root CNA is recommended when the vulnerability affects software covered by other CNAs
Purpose
Prevent assignments of duplicate/overlapping CVE IDs by ensuring that assignments are made at the same level of abstraction
Process
See next slide
Due diligence

30. CNT3: Expanded Decisions
Shared Codebase
Affects a single product; assign one CVE ID
Affects the same code in multiple products; assign a CVE ID to the shared codebase
Affects multiple products but with different code; assign a CVE ID to each product
Not sure or undefined; assign a CVE ID to each product
Libraries, Protocols, Standards, etc.
Results from conforming to the specification (i.e. all implementations must be vulnerable); assign a single CVE ID
Results from a choice by the implementer (implementer makes a decision to use a vulnerable option instead of a secure one); assign a CVE ID to each affected codebase/product
Not sure; assign a CVE ID to each affected codebase

31. Advanced Example: SLOTH for TLS 1.2
Takes advantage of authentication protocols that use weak hashing algorithms
TLS 1.2 is a protocol used for authentication
TLS 1.2 allows the client to negotiate with the server which signature hashing algorithm to use
TLS 1.2 allows for the use of MD5, SHA-1, SHA-224, SHA-256, SHA-384, and SHA-512 for hashing signatures
If a product uses TLS 1.2 and supports MD5 for the signature hashing algorithm, an attacker can use SLOTH to impersonate a client
Should this be considered a problem in the protocol or the implementations of the products?
TLS 1.2 does not require the use of MD5. Therefore, it is an implementation issue. However, the implementation are inheriting the vulnerability from the MD5 standard, and therefore should use the CVE ID for MD5 (CVE ).

32. Inclusion Decisions

33. Inclusion Decisions Overview
In Scope of Authority
CVE IDs should be assigned by the CNA who is responsible for the product
INC2
Is the vulnerability public or will it be made public?
INC3
Customer Controlled
CVE IDs should only be assigned if the users of the product must take some action
INC4
Publicly Available and Licensable
CVE IDs should be assigned to products meant for public distribution
INC5
Duplicates
Check the official CVE List to make duplicates are not assigned

34. INC1: In Scope of Authority
In Scope of Authority: Does the vulnerability report fall into the scope of authority for the CNA. CNAs can only assign CVE IDs to vulnerabilities that are within their scope of authority as defined by their root CNA.
Purpose
Reduce duplicate assignments
Ensure those with the greatest amount of relevant information are making the assignments
Process
Determine which product is affected (CNT3)
Identify CNA with most appropriate scope for vulnerability
Increased emphasis

35. INC1: Identify CNA with Most Appropriate Scope
The scopes of the CNAs are defined at
Not all exceptions to scopes are defined; i.e., not all CNAs define which of their products have reached the end of support
MITRE is working with the CNAs to make the scope definitions as accurate as possible
If a product is explicitly within another CNA’s scope, contact that CNA for an assignment
Sometimes scopes overlap
Multiple CNAs bundle a product when upstream vendor is not a CNA
Multiple CNAs collaborate on an open source product
Different CNAs maintain separate forks of the same open source product
For overlapping scopes
Coordinate with the other CNAs (and the upstream vendor even if it is not a CNA)
If there is a disagreement between the CNAs as to whether an issue is a vulnerability, assign a CVE ID and note the disagreement in the description
If uncertain what to do, contact parent CNA

36. Examples of Overlapping Scopes
Google and Apple working on Webkit
Linux Distros (Red Hat, Canonical, Debian, SUSE)
Oracle and IBM versions of Java
Apple and Google both maintained Webkit and negotiated who would assign a CVE ID to each vulnerability
The Linux distros have a mailing list where common vulnerabilities are posted and the CNAs determine who should assign.
Oracle and IBM maintain their own versions of Java. IBM uses the CVE IDs Oracle assigns.

37. INC2: Intended to be Public
Intended to be Public: Is the vulnerability report or the issue described intended to be published to a publicly available location in the future? CVE IDs are intended to be public information and are not assigned to vulnerabilities that are intended to be private.
Purpose
Ensure CVE ID is usable by the community
Process
Determine if vulnerability is public
If it is, determine if public information meets information requirements defined in Appendix B of CNA Rules
If not already public, determine if the required information will be made public

38. INC2: Determine if Vulnerability is Public (1 of 2)
For a vulnerability to be considered public, it must meet the following conditions:
Must have a URL
The Terms must allow ability to link to the URL
The document linked to the URL must contain the minimum required information for a CVE entry:
Product
Version
Problem type (vulnerability type or impact)
Registration and login requirements are acceptable, but there can be no other restrictions
Advisories that require payment to access are not considered public
If there is a public advisory with the minimum required details and other details require payment to access, then the vulnerability is considered public

39. INC2: Determine if Vulnerability is Public (2 of 2)
Patches are not considered public
They do not meet the URL and information requirements
Exception: Public open source commits (in some cases)
If a researcher wishes to make a vulnerability public, it is best practice for the CNA to assign a CVE ID
If CNA does not assign a CVE ID and the researcher publishes the vulnerability, the CNA’s root CNA may choose to assign on their own

40. INC3: Customer-Controlled Software
Installable/Customer-controlled Software: Is the vulnerability 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? CVE IDs are assigned to products that are customer-controlled or customer-installable.
Purpose
Ensure that CVE IDs are only assigned to vulnerabilities users care about
Process
Determine if the end user of the product can take an action to mitigate the vulnerability

41. INC3 Exclusions INC3 does not include: Software-as-a-Service (SaaS)
Vulnerabilities in an installed thin client would still get assigned CVE IDs
If the vulnerabilities affect both the SaaS version and installable version, CVE IDs are still assigned
Individual websites (e.g., google.com)
Any fix that does not require the user of the product to take action

42. INC4: Publicly Available Software
Generally Available and Licensed Product: Does the vulnerability affect software that is licensed and made generally available to the public? If the vulnerability only affects a version of software that was never made generally available to the publisher’s or vendor's customers, the bug should not be assigned a CVE ID. CVE IDs are not assigned to bugs in malware.
Purpose
Ensure that CVE IDs are only assigned to vulnerabilities users care about
Process
Determine if the vulnerability is in software
Determine if the software was meant to be publicly distributed
Determine if the software was meant to be distributed legally
Meant to rule out vulnerabilities in
Closed Betas
Commits that are fixed before a new release is issued
Malware
Business internal applications

43. INC4 Exclusions INC4 does not include vulnerabilities in: Closed Betas
Commits that are fixed before a new release is issued
Malware
Business internal applications
Hardware
Firmware and microcode count as software

44. INC5: Duplicates Purpose Prevent duplicate assignments Process
Duplicate: Has the vulnerability already been assigned a CVE by you or does it already exist in the CVE List?
Purpose
Prevent duplicate assignments
Process
Check the CVE List for the vulnerability

45. Questions

46. Backup Slides

47. Chains Example: Split into multiple code paths
Insufficient Memory Allocation C
Heap
Overflow D X A B
Use of Signed Integers for Always-Positive Operations
Incorrect
Range
Check
Integer
Overflow
Out-of-bounds
Read E

48. Chains Example: Merge into a single code pathB X A
Integer
Overflow
Insufficient Memory Allocation C
Use of Signed Integers for Always-Positive Operations
Heap
Overflow D
Incorrect
Range
Check