mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 06:25:31 +00:00
Code Issues Releases Wiki Activity

pspacek deleted page: CVSS Scoring Guidelines

Petr Špaček
2024-09-23 11:11:31 +00:00
parent 66b12925d1
commit 775e6e2d03
1 changed files with 0 additions and 104 deletions
Download Patch File Download Diff File Expand all files Collapse all files

104
CVSS-Scoring-Guidelines.md

@@ -1,104 +0,0 @@
This has been published in the KB as https://kb.isc.org/docs/isc-cvss-scoring-guidelines as of Nov 18, 2021. IF YOU UPDATE THIS DOCUMENT, PLEASE EITHER UPDATE THE KB ARTICLE OR NOTIFY MARKETING TO DO SO.
thank you,
Vicky
-----------------
This is a living document based on the CVSS 3.1 specification document and user guide, with specific examples for DNS and BIND.
[[_TOC_]]
## Sources:
* https://www.first.org/cvss/user-guide
* https://www.first.org/cvss/v3.1/specification-document
## 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
* 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)