Pion DTLS is a Go implementation of Datagram Transport Layer Security. Prior to version 2.1.4, a buffer that was used for inbound network traffic had no upper limit. Pion DTLS would buffer all network traffic from the remote user until the handshake completes or timed out. An attacker could exploit this to cause excessive memory usage. Version 2.1.4 contains a patch for this issue. There are currently no known workarounds available.

The affected ThroughTek P2P products (SDKs using versions before 3.1.5, any versions with nossl tag, device firmware not using AuthKey for IOTC conneciton, firmware using AVAPI module without enabling DTLS mechanism, and firmware using P2PTunnel or RDT module) do not sufficiently protect data transferred between the local device and ThroughTek servers. This can allow an attacker to access sensitive information, such as camera feeds.

On F5 BIG-IP LTM, Advanced WAF, ASM, or APM 16.1.x versions prior to 16.1.2.2, 15.1.x versions prior to 15.1.5, 14.1.x versions prior to 14.1.4.6, and all versions of 13.1.x, 12.1.x, and 11.6.x, when a virtual server is configured with HTTP, TCP on one side (client/server), and DTLS on the other (server/client), undisclosed requests can cause the TMM process to terminate. Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated

A vulnerability in the implementation of the Datagram TLS (DTLS) protocol in Cisco Adaptive Security Appliance (ASA) Software and Cisco Firepower Threat Defense (FTD) Software could allow an unauthenticated, remote attacker to cause high CPU utilization, resulting in a denial of service (DoS) condition. This vulnerability is due to suboptimal processing that occurs when establishing a DTLS tunnel as part of an AnyConnect SSL VPN connection. An attacker could exploit this vulnerability by sending a steady stream of crafted DTLS traffic to an affected device. A successful exploit could allow the attacker to exhaust resources on the affected VPN headend device. This could cause existing DTLS tunnels to stop passing traffic and prevent new DTLS tunnels from establishing, resulting in a DoS condition. Note: When the attack traffic stops, the device recovers gracefully.

wolfSSL 5.x before 5.1.1 uses non-random IV values in certain situations. This affects connections (without AEAD) using AES-CBC or DES3 with TLS 1.1 or 1.2 or DTLS 1.1 or 1.2. This occurs because of misplaced memory initialization in BuildMessage in internal.c.

FreeSWITCH is a Software Defined Telecom Stack enabling the digital transformation from proprietary telecom switches to a software implementation that runs on any commodity hardware. When handling SRTP calls, FreeSWITCH prior to version 1.10.7 is susceptible to a DoS where calls can be terminated by remote attackers. This attack can be done continuously, thus denying encrypted calls during the attack. When a media port that is handling SRTP traffic is flooded with a specially crafted SRTP packet, the call is terminated leading to denial of service. This issue was reproduced when using the SDES key exchange mechanism in a SIP environment as well as when using the DTLS key exchange mechanism in a WebRTC environment. The call disconnection occurs due to line 6331 in the source file `switch_rtp.c`, which disconnects the call when the total number of SRTP errors reach a hard-coded threshold (100). By abusing this vulnerability, an attacker is able to disconnect any ongoing calls that are using SRTP. The attack does not require authentication or any special foothold in the caller's or the callee's network. This issue is patched in version 1.10.7.

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.

Eclipse TinyDTLS through 0.9-rc1 relies on the rand function in the C library, which makes it easier for remote attackers to compute the master key and then decrypt DTLS traffic.

Pion WebRTC before 3.0.15 didn't properly tear down the DTLS Connection when certificate verification failed. The PeerConnectionState was set to failed, but a user could ignore that and continue to use the PeerConnection. )A WebRTC implementation shouldn't allow the user to continue if verification has failed.)

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.

In MatrixSSL before 4.2.2 Open, the DTLS server can encounter an invalid pointer free (leading to memory corruption and a daemon crash) via a crafted incoming network message, a different vulnerability than CVE-2019-14431.

An issue was discovered in the DTLS handshake implementation in wolfSSL before 4.5.0. Clear DTLS application_data messages in epoch 0 do not produce an out-of-order error. Instead, these messages are returned to the application.

The UpdateHub module disables DTLS peer checking, which allows for a man in the middle attack. This is mitigated by firmware images requiring valid signatures. However, there is no benefit to using DTLS without the peer checking. See NCC-ZEP-018 This issue affects: zephyrproject-rtos zephyr version 2.1.0 and later versions.

handleIncomingPacket in conn.go in Pion DTLS before 1.5.2 lacks a check for application data with epoch 0, which allows remote attackers to inject arbitrary unencrypted data after handshake completion.

GnuTLS 3.6.x before 3.6.13 uses incorrect cryptography for DTLS. The earliest affected version is 3.6.3 (2018-07-16) because of an error in a 2017-10-06 commit. The DTLS client always uses 32 '\0' bytes instead of a random value, and thus contributes no randomness to a DTLS negotiation. This breaks the security guarantees of the DTLS protocol.

The DoAlert function in the (1) TLS and (2) DTLS implementations in wolfSSL CyaSSL before 2.9.4 allows remote attackers to have unspecified impact and vectors, which trigger memory corruption or an out-of-bounds read.

In MatrixSSL 3.8.3 Open through 4.2.1 Open, the DTLS server mishandles incoming network messages leading to a heap-based buffer overflow of up to 256 bytes and possible Remote Code Execution in parseSSLHandshake in sslDecode.c. During processing of a crafted packet, the server mishandles the fragment length value provided in the DTLS message.

In BIG-IP 14.0.0-14.0.0.2, 13.0.0-13.1.1.1, 12.1.0-12.1.3.6, 11.6.1-11.6.3.2, or 11.5.1-11.5.8, when processing fragmented ClientHello messages in a DTLS session TMM may corrupt memory eventually leading to a crash. Only systems offering DTLS connections via APM are impacted.

ARM mbed TLS before 1.3.22, before 2.1.10, and before 2.7.0, when the truncated HMAC extension and CBC are used, allows remote attackers to execute arbitrary code or cause a denial of service (heap corruption) via a crafted application packet within a TLS or DTLS session.

ARM mbed TLS before 1.3.22, before 2.1.10, and before 2.7.0 allows remote attackers to execute arbitrary code or cause a denial of service (buffer overflow) via a crafted certificate chain that is mishandled during RSASSA-PSS signature verification within a TLS or DTLS session.