CVSS: 8.2EPSS: 0%CPEs: 2EXPL: 0CVE-2022-39368 – Californium Failing DTLS handshakes causes Data Loss due to throttling blocking processing of records
https://notcve.org/view.php?id=CVE-2022-39368
Eclipse Californium is a Java implementation of RFC7252 - Constrained Application Protocol for IoT Cloud services. In versions prior to 3.7.0, and 2.7.4, Californium is vulnerable to a Denial of Service. Failing handshakes don't cleanup counters for throttling, causing the threshold to be reached without being released again. This results in permanently dropping records. The issue was reported for certificate based handshakes, but may also affect PSK based handshakes. • https://github.com/eclipse-californium/californium/commit/5648a0c27c2c2667c98419254557a14bac2b1f3f https://github.com/eclipse-californium/californium/commit/726bac57659410da463dcf404b3e79a7312ac0b9 https://github.com/eclipse-californium/californium/security/advisories/GHSA-p72g-cgh9-ghjg https://access.redhat.com/security/cve/CVE-2022-39368 https://bugzilla.redhat.com/show_bug.cgi?id=2145205 • CWE-404: Improper Resource Shutdown or Release CWE-459: Incomplete Cleanup •
CVSS: 7.5EPSS: 0%CPEs: 2EXPL: 1CVE-2022-2576
https://notcve.org/view.php?id=CVE-2022-2576
In Eclipse Californium version 2.0.0 to 2.7.2 and 3.0.0-3.5.0 a DTLS resumption handshake falls back to a DTLS full handshake on a parameter mismatch without using a HelloVerifyRequest. Especially, if used with certificate based cipher suites, that results in message amplification (DDoS other peers) and high CPU load (DoS own peer). The misbehavior occurs only with DTLS_VERIFY_PEERS_ON_RESUMPTION_THRESHOLD values larger than 0. En Eclipse Californium versiones 2.0.0 a 2.7.2 y 3.0.0-3.5.0, un handshake de reanudación DTLS retrocede a un handshake completo DTLS en caso de desajuste de parámetros sin usar un HelloVerifyRequest. Especialmente, si es usado con suites de cifrado basadas en certificados, eso resulta en una amplificación de mensajes (DDoS otros pares) y alta carga de CPU (DoS propio par). • https://bugs.eclipse.org/580018 • CWE-408: Incorrect Behavior Order: Early Amplification •
CVSS: 7.5EPSS: 0%CPEs: 4EXPL: 0CVE-2021-34433
https://notcve.org/view.php?id=CVE-2021-34433
In Eclipse Californium version 2.0.0 to 2.6.4 and 3.0.0-M1 to 3.0.0-M3, the certificate based (x509 and RPK) DTLS handshakes accidentally succeeds without verifying the server side's signature on the client side, if that signature is not included in the server's ServerKeyExchange. En Eclipse Californium versiones 2.0.0 a 2.6.4 y 3.0.0-M1 a 3.0.0-M3, los handshakes DTLS basados en certificados (x509 y RPK) presentan éxito accidentalmente sin verificar la firma del lado del servidor en el lado del cliente, si esa firma no está incluida en el ServerKeyExchange del servidor. • https://bugs.eclipse.org/bugs/show_bug.cgi?id=575281 • CWE-322: Key Exchange without Entity Authentication CWE-347: Improper Verification of Cryptographic Signature •
CVSS: 7.5EPSS: 0%CPEs: 1EXPL: 0CVE-2020-27222 – californium-core: DTLS - DoS vulnerability for certificate based handshakes
https://notcve.org/view.php?id=CVE-2020-27222
In Eclipse Californium version 2.3.0 to 2.6.0, the certificate based (x509 and RPK) DTLS handshakes accidentally fails, because the DTLS server side sticks to a wrong internal state. That wrong internal state is set by a previous certificate based DTLS handshake failure with TLS parameter mismatch. The DTLS server side must be restarted to recover this. This allow clients to force a DoS. En Eclipse Californium versiones 2.3.0 hasta 2.6.0, los protocolos de enlace DTLS basados ?? • https://bugs.eclipse.org/bugs/show_bug.cgi?id=570844 https://access.redhat.com/security/cve/CVE-2020-27222 https://bugzilla.redhat.com/show_bug.cgi?id=1930230 • CWE-372: Incomplete Internal State Distinction •