Review INC4

[EvansJonathan]

GOAL: Clarify the CNA Rules CHANGE: Update the wording for INC4. This decision may need to be split into multiple decisions. OUTCOME: The Counting Rules are easier to implement.

[kurtseifried]

Should we add some specific examples, e.g. "Chrome beta" but it had millions of users, or perhaps use of said software, e.g. a beta of bind used by a few percent of root servers... might matter. etc.

[chandanbn]

Suggestion:

INC4 - Generally Available and Licensed Product:

Suggested: INC4 - Vulnerability or weakness results in an exposure:

Does the vulnerability affect software that is licensed and made generally available to the public?

Suggested: Can the product have instances that have an exposure as a result of this vulnerability?

yes: continue, no: exit, do not assign CVE ID. not-sure: continue

Exposure : An instance has an exposure due to a vulnerability when 'the probability of exploitation of the vulnerability with an adverse impact is greater than zero'.

An instance is a realization of computing logic (source code, specification or design). A vulnerability in source code (or on paper, CDs, storage media) can be considered harmless until there exists an actual computer running that software (or a derived software). Same applies to hardware: A circuit diagram on paper is harmless until there exists a real hardware based on that design.

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.

If the vulnerability does not have and can not have instances where it can be exploited, do not assign a CVE ID. If this can not be determined or there is not enough information to determine this, assign a CVE ID.

Examples: 1. A developer commits a change with a buffer overflow vulnerability into the bleeding edge version of an open source software. The mistake is recognized two days later. It is determined that since the introduction of the vulnerability, there have been no downloads of any kind. A CVE ID is not assigned.

Example 2. A hardware vendor realizes that a recent batch of equipment leaked sensitive information through radio waves, allowing physically close attackers to capture this information. The vendor recalls the devices from store shelves and determines that none of them were ever sold. A CVE ID is not assigned.

Example 3. A stack buffer overflow vulnerability only overflows two bytes into a padding region that would never get used again. This is determined to be not exploitable and a A CVE ID is not assigned. A CVE ID should have been assigned if this can not be determined or is unknown.

Example 4. A vulnerability in a cloud service had made consumer private information available as a file downloadable without authentication over the Internet. From the logs and audit trails it is determined that the file had never been accessed or downloaded. A CVE ID is not assigned. (See Issue #18). A CVE ID should have been assigned if there was proof of unauthorized access or if that is not known (assuming the worst).

Example 5. A text book contains an example code in C, which when compiled into software can result in exploitable vulnerability. A CVE ID is assigned.

[dadinolfi]

CVE currently has a definition of the term "exposure" on its website:

http://cve.mitre.org/about/terminology.html

"An "exposure" is a system configuration issue or a mistake in software that allows access to information or capabilities that can be used by a hacker as a stepping-stone into a system or network..."

Is there another term we can use for @chandanbn's suggestion that isn't exposure?

[chandanbn]

Is there another term we can use for @chandanbn's suggestion that isn't exposure?

How about:

'Is there a risk of exploitation leading to an impact on confidentiality, integrity and availability' ? Yes, unknown: continue to next rule, no: do not assign CVE ID.

Do not assign CVE ID if the risk of exploitation on any instance of the product is zero. Continue to next rule if this is not known or a risk of exploitation exists.

The idea behind this rule seems to be to avoid assigning CVE ids to products that have not been put to real use i.e "the rubber hasn't met the road yet situations"

Another suggestion:

'Are there users or instances of the product which could be potentially impacted by this issue?' Yes, unknown : continue next rule, no: do not assign CVE ID.

[dadinolfi]

'Are there users or instances of the product which could be potentially impacted by this issue?' Yes, unknown : continue next rule, no: do not assign CVE ID.

This wording is the core of the question for INC4. We don't want CVE IDs to be assigned to vulnerabilities that are not available to anyone outside of the developers themselves.

That said, we specifically ask about Licensing to help avoid assigning CVE IDs to malware (though some entrepreneurial criminals have licensed version of their malware, in some cases, so maybe it is less of a discriminator). Is there agreement that the licensing aspect of INC4 is no longer relevant?

[EvansJonathan]

Here are the examples of things the original INC4 was meant to rule out:

• Closed Betas
• Commits that are fixed before a new release is issued
• Malware
• Business internal applications
• Hardware
  • Firmware and microcode count as software

'Is there a risk of exploitation leading to an impact on confidentiality, integrity and availability' ?

I am not sure how much this adds compared to CNT2.

'Are there users or instances of the product which could be potentially impacted by this issue?'

I think this is problematic for my second example since most open source projects won't know if someone has downloaded and compiled the vulnerable code.

[chandanbn]

Re: Malware: I am not suggesting changing the note about malware that is already there. "CVE IDs are not assigned to bugs in malware." is good enough.

Vulnerabilities in malware may not create an exposure more than what the malware or factors leading to malware infestation may have already created.

I am not sure how much this adds compared to CNT2.

CNT2 asks if it is a vulnerability or not. In the example 1 above, the bug found is a vulnerability and satisfies CNT2, but does not get a CVE ID because no one is impacted.

I think this is problematic for my second example since most open source projects won't know if someone has downloaded and compiled the vulnerable code.

When in doubt assign a CVE ID. All open source software, with an open source license is considered 'generally available' and is also 'licensed'. According to old wordings that would mean that a short lived commit with a bug should have gotten a CVE. Suggested wordings give an option to not assign a CVE ID, if the open source developer can claim that no one is ever impacted. If that can't be claimed, assign a CVE ID.

[dadinolfi]

Suggestion: Changing the last sentence of INC4 to read:

CVE IDs are not assigned to bugs in malware, closed betas, commits that were fixed before a new release is issued, applications used only within a single organization (such as a unique, custom-built system).