CVE Team CNA Rules 2.0: Counting Rules Overview
Description: CVE Team CNA Rules 2.0: Counting Rules Overview Explain what Counting Rules are and why they exist Review each rule Explain the rules and provide guidance where the rules are undefined Definition and Purpose The CVE Counting Rules define
Related Topics
Download Presentation
"CVE Team CNA Rules 2.0: Counting Rules Overview" is the property of its rightful owner. Permission is granted to download and print the materials on this website for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Presentation Transcript
slide1. CVE Team CNA Rules 2.0: Counting Rules<br>
slide2. Overview Explain what Counting Rules are and why they exist
Review each rule
Explain the rules and provide guidance where the rules are undefined<br>
slide3. 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<br>
slide4. Is there an established method to count vulnerabilities? | 3 |<br>
slide5. 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]<br>
slide6. 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.<br>
slide7. Methods of Separating Vulnerabilities All of these methods have been
used by vulnerability databases<br>
slide8. 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<br>
slide9. 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<br>
slide10. 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.<br>
slide11. Counting Rules | 10 |<br>
slide12. Counting Rules Structure Counting Decisions
Number of vulnerabilities
Inclusion Decision
Whether or not a CVE ID should be assigned
Who should do the assignment<br>
slide13. Counting Decisions Overview<br>
slide14. CNT1: Split by Independently Fixable Groups of Bugs 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<br>
slide15. 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<br>
slide16. 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<br>
slide17. 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<br>
slide18. 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? | 17 |<br>
slide19. 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 | 18 |<br>
slide20. 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<br>
slide21. Chains: Not Independently Fixable Integer
Overflow Incorrect
Range
Check Heap
Overflow Insufficient Memory Allocation A B C D height = -65534; width = -65534 Assumption: The range check will prevent an overflow from occurring. Use of Signed Integers for Always-Positive Operations X<br>
slide22. Chains: Possible Fixes 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 Integer
Overflow Incorrect
Range
Check Heap
Overflow Insufficient Memory Allocation A B D Use of Signed Integers for Always-Positive Operations X C<br>
slide23. 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<br>
slide24. CNT2.1: Vendor Acknowledgement Process
Determine product vendor
Determine if the vulnerability is acknowledged
Determine if the acknowledgement says there is a negative impact<br>
slide25. 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<br>
slide26. CNT2.2: Vulnerability Models 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<br>
slide27. 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 CNT2.2: Security Model vs. Vulnerability Claim<br>
slide28. Security Model 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 Vulnerability Claim 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 Stored XSS vulnerability in the admin page of a WordPress module allows unauthenticated attackers to obtain cookies CNT2.2: Example<br>
slide29. CNT3: Shared Codebase, Library, Protocol, etc. Purpose
Prevent assignments of duplicate/overlapping CVE IDs by ensuring that assignments are made at the same level of abstraction
Process
See next slide<br>
slide30. 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<br>
slide31. Advanced Example: SLOTH for TLS 1.2 SLOTH
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?<br>
slide32. Inclusion Decisions | 31 |<br>
slide33. Inclusion Decisions Overview<br>
slide34. INC1: In Scope of Authority 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<br>
slide35. INC1: Identify CNA with Most Appropriate Scope The scopes of the CNAs are defined at http://cve.mitre.org/cve/request_id.html#cna_coverage.html
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<br>
slide36. Examples of Overlapping Scopes Google and Apple working on Webkit
Linux Distros (Red Hat, Canonical, Debian, SUSE)
Oracle and IBM versions of Java<br>
slide37. INC2: Intended to be Public 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<br>
slide38. 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<br>
slide39. 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<br>
slide40. INC3: Customer-Controlled Software 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<br>
slide41. 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<br>
slide42. INC4: Publicly Available Software 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<br>
slide43. 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<br>
slide44. INC5: Duplicates Purpose
Prevent duplicate assignments
Process
Check the CVE List for the vulnerability
http://cve.mitre.org/cve/cve.html<br>
slide45. Questions | 44 |<br>
slide46. Backup Slides | 45 |<br>
slide47. Chains Example: Split into multiple code paths Integer
Overflow Incorrect
Range
Check A B Use of Signed Integers for Always-Positive Operations X<br>
slide48. Chains Example: Merge into a single code path Integer
Overflow Incorrect
Range
Check A B Use of Signed Integers for Always-Positive Operations X<br>
slide2. Overview Explain what Counting Rules are and why they exist
Review each rule
Explain the rules and provide guidance where the rules are undefined<br>
slide3. 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<br>
slide4. Is there an established method to count vulnerabilities? | 3 |<br>
slide5. 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]<br>
slide6. 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.<br>
slide7. Methods of Separating Vulnerabilities All of these methods have been
used by vulnerability databases<br>
slide8. 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<br>
slide9. 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<br>
slide10. 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.<br>
slide11. Counting Rules | 10 |<br>
slide12. Counting Rules Structure Counting Decisions
Number of vulnerabilities
Inclusion Decision
Whether or not a CVE ID should be assigned
Who should do the assignment<br>
slide13. Counting Decisions Overview<br>
slide14. CNT1: Split by Independently Fixable Groups of Bugs 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<br>
slide15. 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<br>
slide16. 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<br>
slide17. 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<br>
slide18. 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? | 17 |<br>
slide19. 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 | 18 |<br>
slide20. 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<br>
slide21. Chains: Not Independently Fixable Integer
Overflow Incorrect
Range
Check Heap
Overflow Insufficient Memory Allocation A B C D height = -65534; width = -65534 Assumption: The range check will prevent an overflow from occurring. Use of Signed Integers for Always-Positive Operations X<br>
slide22. Chains: Possible Fixes 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 Integer
Overflow Incorrect
Range
Check Heap
Overflow Insufficient Memory Allocation A B D Use of Signed Integers for Always-Positive Operations X C<br>
slide23. 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<br>
slide24. CNT2.1: Vendor Acknowledgement Process
Determine product vendor
Determine if the vulnerability is acknowledged
Determine if the acknowledgement says there is a negative impact<br>
slide25. 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<br>
slide26. CNT2.2: Vulnerability Models 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<br>
slide27. 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 CNT2.2: Security Model vs. Vulnerability Claim<br>
slide28. Security Model 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 Vulnerability Claim 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 Stored XSS vulnerability in the admin page of a WordPress module allows unauthenticated attackers to obtain cookies CNT2.2: Example<br>
slide29. CNT3: Shared Codebase, Library, Protocol, etc. Purpose
Prevent assignments of duplicate/overlapping CVE IDs by ensuring that assignments are made at the same level of abstraction
Process
See next slide<br>
slide30. 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<br>
slide31. Advanced Example: SLOTH for TLS 1.2 SLOTH
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?<br>
slide32. Inclusion Decisions | 31 |<br>
slide33. Inclusion Decisions Overview<br>
slide34. INC1: In Scope of Authority 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<br>
slide35. INC1: Identify CNA with Most Appropriate Scope The scopes of the CNAs are defined at http://cve.mitre.org/cve/request_id.html#cna_coverage.html
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<br>
slide36. Examples of Overlapping Scopes Google and Apple working on Webkit
Linux Distros (Red Hat, Canonical, Debian, SUSE)
Oracle and IBM versions of Java<br>
slide37. INC2: Intended to be Public 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<br>
slide38. 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<br>
slide39. 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<br>
slide40. INC3: Customer-Controlled Software 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<br>
slide41. 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<br>
slide42. INC4: Publicly Available Software 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<br>
slide43. 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<br>
slide44. INC5: Duplicates Purpose
Prevent duplicate assignments
Process
Check the CVE List for the vulnerability
http://cve.mitre.org/cve/cve.html<br>
slide45. Questions | 44 |<br>
slide46. Backup Slides | 45 |<br>
slide47. Chains Example: Split into multiple code paths Integer
Overflow Incorrect
Range
Check A B Use of Signed Integers for Always-Positive Operations X<br>
slide48. Chains Example: Merge into a single code path Integer
Overflow Incorrect
Range
Check A B Use of Signed Integers for Always-Positive Operations X<br>