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.

Sources:
Base Principles
By CVSS Section

Sources:

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. 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

[We could assume, as OpenSSL does, that any feature/configuration we deem is rarely used, by definition cannot trigger a high or critical severity issue

bconry: exempting things because of our assessment of them being "rarely used" is counter to the "CVSS Base Score Measures Severity, not Risk" principle above. This document is about scoring, not about how we handle incidents. If we want to treat vulnerabilities as lower priority when we feel that the feature/configuration is "rarely used" then that is something that should go in our incident handling policy as it doesn't affect the scoring of those vulnerabilities.]

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:
- is primary for a zone that the target system is secondary for (covers both RPZ and catz)
- has XFR privileges for one or more zones the target server is authoritative for
- has a key for rndc that allows only read-only operations
- has credentials that BIND can validate using GSSAPI
- knows the secret for any configured key
H - High - attacker must have admin privileges over the target system

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.

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