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. References: https://bugs.eclipse.org/bugs/show_bug.cgi?id=570844
Marking Red Hat Fuse 7 and Red Hat Integration Camel K as having a moderate impact as although the vulnerable org.eclipse.californium:scandium:jar:* artifact is used as part of camel-coap the impact is lessened due to the following reasons - * A successful attack on the component would not result in a total loss of availability. * Only the coaps (UDP + DTLS) protocol is impacted by this flaw, this increases the attack complexity as the configuration of camel-coap is beyond the attackers control. Further extenuating factors which we have not taken into account for the impact of this flaw but which might be a factor in considering the risk an end application may be exposed to, is that CoAP networks are often not accessible to WAN traffic, therefore the attack vector would likely be Adjacent as opposed to Network in those situations.
This issue has been addressed in the following products: Red Hat Integration Via RHSA-2021:3205 https://access.redhat.com/errata/RHSA-2021:3205
This issue has been addressed in the following products: Red Hat Integration Via RHSA-2021:3207 https://access.redhat.com/errata/RHSA-2021:3207
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-27222