CVSS: 7.5EPSS: 5%CPEs: 21EXPL: 1CVE-2023-50387 – bind9: KeyTrap - Extreme CPU consumption in DNSSEC validator
https://notcve.org/view.php?id=CVE-2023-50387
Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the "KeyTrap" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records. Ciertos aspectos DNSSEC del protocolo DNS (en RFC 4035 y RFC relacionados) permiten a atacantes remotos provocar una denegación de servicio (consumo de CPU) a través de una o más respuestas DNSSEC cuando hay una zona con muchos registros DNSKEY y RRSIG, también conocido como "KeyTrap". " asunto. La especificación del protocolo implica que un algoritmo debe evaluar todas las combinaciones de registros DNSKEY y RRSIG. Processing specially crafted responses coming from DNSSEC-signed zones can lead to uncontrolled CPU usage, leading to a Denial of Service in the DNSSEC-validating resolver side. This vulnerability applies only for systems where DNSSEC validation is enabled. • https://github.com/knqyf263/CVE-2023-50387 http://www.openwall.com/lists/oss-security/2024/02/16/2 http://www.openwall.com/lists/oss-security/2024/02/16/3 https://access.redhat.com/security/cve/CVE-2023-50387 https://bugzilla.suse.com/show_bug.cgi?id=1219823 https://docs.powerdns.com/recursor/security-advisories/powerdns-advisory-2024-01.html https://gitlab.nic.cz/knot/knot-resolver/-/releases/v5.7.1 https://kb.isc.org/docs/cve-2023-50387 https://lists&# • CWE-400: Uncontrolled Resource Consumption CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 7.5EPSS: 0%CPEs: 18EXPL: 0CVE-2023-4236 – named may terminate unexpectedly under high DNS-over-TLS query load
https://notcve.org/view.php?id=CVE-2023-4236
A flaw in the networking code handling DNS-over-TLS queries may cause `named` to terminate unexpectedly due to an assertion failure. This happens when internal data structures are incorrectly reused under significant DNS-over-TLS query load. This issue affects BIND 9 versions 9.18.0 through 9.18.18 and 9.18.11-S1 through 9.18.18-S1. Una falla en el código de red que maneja consultas DNS sobre TLS puede causar que "named" finalice inesperadamente debido a una falla de aserción. Esto sucede cuando las estructuras de datos internas se reutilizan incorrectamente bajo una carga significativa de consultas DNS sobre TLS. Este problema afecta a las versiones 9.18.0 a 9.18.18 y 9.18.11-S1 a 9.18.18-S1 de BIND 9. • http://www.openwall.com/lists/oss-security/2023/09/20/2 https://kb.isc.org/docs/cve-2023-4236 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IPJLLTJCSDJJII7IIZPLTBQNWP7MZH7F https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U35OARLQCPMVCBBPHWBXY5M6XJLD2TZ5 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VSK5V4W4OHPM3JTJGWAQD6CZW7SFD75B https://security.netapp.com/advisory/ntap-20231013-0004 https:/& • CWE-617: Reachable Assertion •
CVSS: 7.5EPSS: 0%CPEs: 38EXPL: 0CVE-2023-3341 – A stack exhaustion flaw in control channel code may cause named to terminate unexpectedly
https://notcve.org/view.php?id=CVE-2023-3341
The code that processes control channel messages sent to `named` calls certain functions recursively during packet parsing. Recursion depth is only limited by the maximum accepted packet size; depending on the environment, this may cause the packet-parsing code to run out of available stack memory, causing `named` to terminate unexpectedly. Since each incoming control channel message is fully parsed before its contents are authenticated, exploiting this flaw does not require the attacker to hold a valid RNDC key; only network access to the control channel's configured TCP port is necessary. This issue affects BIND 9 versions 9.2.0 through 9.16.43, 9.18.0 through 9.18.18, 9.19.0 through 9.19.16, 9.9.3-S1 through 9.16.43-S1, and 9.18.0-S1 through 9.18.18-S1. El código que procesa los mensajes del canal de control enviados a "named" llama a ciertas funciones de forma recursiva durante el análisis de paquetes. La profundidad de la recursividad sólo está limitada por el tamaño máximo de paquete aceptado; Dependiendo del entorno, esto puede provocar que el código de análisis de paquetes se quede sin memoria disponible, lo que provocará que "named" finalice inesperadamente. • http://www.openwall.com/lists/oss-security/2023/09/20/2 https://kb.isc.org/docs/cve-2023-3341 https://lists.debian.org/debian-lts-announce/2024/01/msg00021.html https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/IPJLLTJCSDJJII7IIZPLTBQNWP7MZH7F https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U35OARLQCPMVCBBPHWBXY5M6XJLD2TZ5 https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/VSK5V4W4OHPM3JTJGWAQD6CZW7SFD • CWE-20: Improper Input Validation CWE-787: Out-of-bounds Write •
CVSS: 7.5EPSS: 0%CPEs: 21EXPL: 0CVE-2023-2828 – named's configured cache size limit can be significantly exceeded
https://notcve.org/view.php?id=CVE-2023-2828
Every `named` instance configured to run as a recursive resolver maintains a cache database holding the responses to the queries it has recently sent to authoritative servers. The size limit for that cache database can be configured using the `max-cache-size` statement in the configuration file; it defaults to 90% of the total amount of memory available on the host. When the size of the cache reaches 7/8 of the configured limit, a cache-cleaning algorithm starts to remove expired and/or least-recently used RRsets from the cache, to keep memory use below the configured limit. It has been discovered that the effectiveness of the cache-cleaning algorithm used in `named` can be severely diminished by querying the resolver for specific RRsets in a certain order, effectively allowing the configured `max-cache-size` limit to be significantly exceeded. This issue affects BIND 9 versions 9.11.0 through 9.16.41, 9.18.0 through 9.18.15, 9.19.0 through 9.19.13, 9.11.3-S1 through 9.16.41-S1, and 9.18.11-S1 through 9.18.15-S1. A vulnerability was found in BIND. The effectiveness of the cache-cleaning algorithm used in named can be severely diminished by querying the resolver for specific RRsets in a certain order, effectively allowing the configured max-cache-size limit to exceed significantly. • http://www.openwall.com/lists/oss-security/2023/06/21/6 https://kb.isc.org/docs/cve-2023-2828 https://lists.debian.org/debian-lts-announce/2023/07/msg00021.html https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SEFCEVCTYEMKTWA7V7EYPI5YQQ4JWDLI https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/U3K6AJK7RRSR53HRF5GGKPA6PDUDWOD2 https://security.netapp.com/advisory/ntap-20230703-0010 https://www.debian.org/security/2023/dsa-5439& • CWE-770: Allocation of Resources Without Limits or Throttling •
CVSS: 7.5EPSS: 0%CPEs: 9EXPL: 0CVE-2022-3924 – named configured to answer from stale cache may terminate unexpectedly at recursive-clients soft quota
https://notcve.org/view.php?id=CVE-2022-3924
This issue can affect BIND 9 resolvers with `stale-answer-enable yes;` that also make use of the option `stale-answer-client-timeout`, configured with a value greater than zero. If the resolver receives many queries that require recursion, there will be a corresponding increase in the number of clients that are waiting for recursion to complete. If there are sufficient clients already waiting when a new client query is received so that it is necessary to SERVFAIL the longest waiting client (see BIND 9 ARM `recursive-clients` limit and soft quota), then it is possible for a race to occur between providing a stale answer to this older client and sending an early timeout SERVFAIL, which may cause an assertion failure. This issue affects BIND 9 versions 9.16.12 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.12-S1 through 9.16.36-S1. Este problema puede afectar a los solucionadores BIND 9 con `stale-answer-enable yes;` que también utilizan la opción `stale-answer-client-timeout`, configurada con un valor mayor que cero. Si el solucionador recibe muchas consultas que requieren recursividad, habrá un aumento correspondiente en la cantidad de clientes que están esperando que se complete la recursividad. Si ya hay suficientes clientes esperando cuando se recibe una nueva consulta de cliente, por lo que es necesario SERVFAIL al cliente que espera más tiempo (consulte el límite y la cuota suave de `clientes recursivos` de BIND 9 ARM), entonces es posible que se produzca una carrera. entre proporcionar una respuesta obsoleta a este cliente anterior y enviar un SERVFAIL de tiempo de espera anticipado, que puede provocar un error de aserción. • https://kb.isc.org/docs/cve-2022-3924 https://access.redhat.com/security/cve/CVE-2022-3924 https://bugzilla.redhat.com/show_bug.cgi?id=2164039 • CWE-20: Improper Input Validation CWE-617: Reachable Assertion •