Описание
When a provide-xfr is given with a tls-auth-name, a secondary requesting a transfer should provide a client certificate with that name. However, no client certificate is needed when the request comes in over TLS over the regular tls-port (and not the tls-auth-port) or over over TCP over the regular port, when the other conditions of the provide-xfr rule match.
A flaw was found in nsd. When a 'provide-xfr' is configured with a 'tls-auth-name', the server incorrectly allows zone transfers without requiring a client certificate if the request comes over TLS on the regular 'tls-port' or over TCP on the regular port, provided other access control conditions are met. This authentication bypass allows an attacker to perform unauthorized zone transfers, leading to information disclosure.
Отчет
This flaw is rated as Moderate. The nsd DNS server, when configured for zone transfers with provide-xfr and tls-auth-name, can bypass client certificate verification. This allows unauthorized zone transfers and information disclosure if requests are made over the regular TLS or TCP port, as the tls-auth-xfr-only option is not enabled by default.
This vulnerability doesn't affect any supported Red Hat Product.
Дополнительная информация
Статус:
EPSS
7.5 High
CVSS3
Связанные уязвимости
When a provide-xfr is given with a tls-auth-name, a secondary requesting a transfer should provide a client certificate with that name. However, no client certificate is needed when the request comes in over TLS over the regular tls-port (and not the tls-auth-port) or over over TCP over the regular port, when the other conditions of the provide-xfr rule match.
When a provide-xfr is given with a tls-auth-name, a secondary requesting a transfer should provide a client certificate with that name. However, no client certificate is needed when the request comes in over TLS over the regular tls-port (and not the tls-auth-port) or over over TCP over the regular port, when the other conditions of the provide-xfr rule match.
When a provide-xfr is given with a tls-auth-name, a secondary requesti ...
When a provide-xfr is given with a tls-auth-name, a secondary requesting a transfer should provide a client certificate with that name. However, no client certificate is needed when the request comes in over TLS over the regular tls-port (and not the tls-auth-port) or over over TCP over the regular port, when the other conditions of the provide-xfr rule match.
EPSS
7.5 High
CVSS3