... | @@ -25,10 +25,7 @@ This is explicit in the CVSS 3.1 specification. |
... | @@ -25,10 +25,7 @@ This is explicit in the CVSS 3.1 specification. |
|
Extending this to DNS and DNS servers, scoring should assume that:
|
|
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 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 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
|
|
[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
|
|
## By CVSS Section
|
|
|
|
|
... | | ... | |