ISC CVSS Scoring Guidelines

This is a living document based on the CVSS 3.1 specification document and user guide, with specific examples for DNS and BIND. We use these guidelines in scoring vulnerabilities, which are then disclosed according to our ISC Software Defect and Security Vulnerability Disclosure Policy.

Sources:

• FIRST CVSS User Guide
• CVSS v3.1 Specification

Base Principles

CVSS Base Score Measures Severity, not Risk

Scoring is to be based on the intrinsic characteristics of the vulnerability - those things which are constant over time and across the entire user base.

The CVSS Base Score does not change based on what details are public, what exploit tools may exist, what poorly-behaved servers are on the internet, or what zones and zone data are known.

Scoring Should Assume Detailed Knowledge

That is, the attacker should be assumed to have specific configuration knowledge about their target. For BIND, this includes views, zones, ACLs, and key names. It does not include any secrets.

Assume Vulnerable Configurations

This is explicit in the CVSS 3.1 specification.

Extending this to DNS and DNS servers, scoring should assume that:

• if an exploit depends on there being an authoritative server that misbehaves in a certain way, that such a server exists and is known to the attacker
• if an exploit depends on there being an authoritative zone with specific data, that such a zone exists and is known to the attacker
• if an exploit depends on a feature/configuration that we deem to be "rarely used", that it is in fact used more commonly than we believe

By CVSS Section

Attack Vector (AV)

• N - Network - For named most attacks will be Network. This includes attacks that need to be executed on-path, which is given as an example in the specification. When the attacker is required to be on-path the Attack Complexity is automatically considered to be High.
• A - Adjacent - This only applies if, and only if, the attack must be executed from a directly-connected network and cannot be routed, e.g. having to originate from an IPv6 link-local interface.
• L - Local - This would apply only if local files are manipulated to accomplish the attack. If the attack requires write-access to configuration or zone files explicitly listed in the configuration then we probably won't consider it to be an "attack", as it will require, effectively, full DNS admin privileges. On the other hand, if there were a weakness in our handling of temporary files then that may be considered an attack requiring "Low" privileges.
• P - Physical - Since we have no physical product, this will never apply to BIND

Attack Complexity (AC)

• L - Low
• H - High - some examples
  • Attacker must execute repeatedly to win a race condition (given in the specification)
  • Attacker must be on-path for a Network attack
  • Attacker must have access to sequence numbers (query IDs for DNS), shared secrets (we would normally consider this to also have Low or High privileges), or knowledge of configuration of other systems (e.g. firewalls)

Privileges Required (PR)

• N - None - matching allow-query (and friends) is not "privileges", not even for an attack that must be performed over TCP
• L - Low - the attacker has some privileges, but is not an admin.
  Some DNS specific examples:
  • has XFR privileges for one or more zones the target server is authoritative for
  • has credentials that BIND can validate using GSSAPI
  • knows the secret for any configured key
• H - High - attacker must have administrative privileges on the target system or access via an administrative channel that needs to be explicitly configured by the operator, e.g.:
  • is primary for a zone that the target system is secondary for (covers both RPZ and catz in addition to normal zones)
  • has access to an rndc key configured for a given named instance
  • has access to the statistics channel configured for a given named instance

User Interaction (UI)

• N - None
• R - Required
  • "A user or admin must take action as part of the attack."
  • For daemons there really isn't any user interaction possible, unless one maybe counts running a specific rndc command after the attacker does something.
  • Other possibilities are the Windows installer and the various other command-line tools such as DiG.

Scope (S)

• U - Unchanged - only the specified component (typically named) is affected
• C - Changed - the attack gives the attacker the ability to affect things outside of the directly-affected component. The canonical DNS example of this is cache poisoning.

Confidentiality ((C)

• N - None
• L - Low - attacker is able to obtain data that is not intended to be readily disclosed but is "ordinary" data
  • regular zone contents, even for zones that an attacker would not otherwise be able to query
  • policy zone contents
  • catalog zone contents, except when/if they might contain encryption key data (not just the key name)
• H - High - attacker is able to obtain "high value" data, such as passwords or encryption keys

Integrity (I)

• N - None
• L - Low - attacker is able to modify data, but not control what data is modified and/or what it is modified to
• H - High - attacker is able to modify data. Note that this will almost always imply Scope:Changed as well.
  • zone update ACL bypass
  • cache poisoning

Availability (A)

• N - None
• L - Low - Any impairment in which "the attacker does not have the ability to completely deny service to legitimate users"
• H - High - the attacker is able to completely deny service to legitimate users
  • explicitly includes cases where the impairment lasts only as long as the attacker is able to deliver the attack
  • explicitly includes cases where the attacker is able to eventually cause complete loss of service (the example given is a small memory leak that will lead to memory exhaustion with continued exploitation)

Temporal Metrics - no longer used

ISC applied the temporal metrics, using the guidelines listed below, for about a year. We found that these additional factors did not result in CVSS scores that more accurately reflected our sense of the issue severity, and they introduced more confusion and questions in the scoring process. So, as of September, 2022, we ceased using the temporal metrics.

Exploit Code Maturity (E)

• X - Not Defined
  • not something we should use in scoring for release
• H - High
  • "Functional autonomous code exists, or no exploit is required (manual trigger) and details are widely available." [emphasis added]
  • This seems like it would apply to anything that is triggered based on a query response
• F - Functional
  • this seems to be a middle ground that we won't often use
• P - Proof-of-Concept
  • If we release system tests that attempt to trigger the exploit then we have at least proof-of-concept level.
• U - Unproven
  • When we haven't even proven that it's possible to exploit

Remediation Level (RL)

• X - Not Defined
  • will never apply at announcement time
• U - Unavailable
  • hopefully we never end up here
• W - Workaround
  • will never apply at announcement time (see below)
• T - Temporary Fix
  • per the specification, if we describe a workaround then it qualifies as a Temporary Fix because it came from the "vendor" (us).
  • We might use this in Operational Notifications where we aren't releasing patches.
• O - Official Fix
  • This will generally be what we use at announcement time.

Report Confidence (RC)

• X - Not Defined
  • should never apply at announcement time
• C - Confirmed
  • "or the author or vendor of the affected code has confirmed the presence of the vulnerability"
  • unless we're going public with information we're not sure about, this is where we're going to be
• R - Reasonable
  • We might use this if we're making an announcement based on reliable reports from something being actively exploited "in the wild" that we haven't yet diagnosed or directly observed
• U - Unknown
  • We're unlikely to make a public announcement at this level of confidence, unless we're getting conflicting reports that we're unable to verify