Alfredfarrugia

The issue is caused by a race condition in the hello handshake phase of the DTLS protocol when handling DTLS-SRTP for media setup. This can be exploited by a remote attacker to cause a denial of service, potentially leading to a massive denial of service on vulnerable Asterisk servers for calls that rely on DTLS-SRTP. The attack can be done continuously, thus denying new DTLS-SRTP encrypted calls during the attack.

OpenSIPS is a Session Initiation Protocol (SIP) server implementation. When a specially crafted SIP message is processed by the function `rewrite ruri`, a crash occurs due to a segmentation fault, causing the server to crash. This issue affects configurations containing functions that make use of the affected code, such as the function `setport`.

OpenSIPS is a Session Initiation Protocol (SIP) server implementation. A specially crafted Authorization header causes OpenSIPS to crash or behave in an unexpected way due to a bug in the function `parse param name()`. This issue was discovered while performing coverage guided fuzzing of the function `parse msg`. The AddressSanitizer identified that the issue occurred in the function `q memchr()` which is being called by the function `parse param name()`. This issue may cause erratic program behaviour or a server crash. It affects configurations containing functions that make use of the affected code, such as the function `www authorize()`.

The issue allows remote attackers to terminate calls by flooding a media port handling SRTP traffic with specially crafted SRTP packets, leading to denial of service. This can be done continuously, denying encrypted calls during the attack. The call disconnection occurs due to a hard-coded threshold of 100 SRTP errors in the source file `switch rtp.c`. The attack does not require authentication or any special foothold in the caller's or the callee's network. This issue was reproduced in both SIP and WebRTC environments using the SDES and DTLS key exchange mechanisms, respectively.

Name of the Vulnerable Software and Affected Versions: Coturn versions prior to 4.5.2 Description: The issue is related to incorrect input validation in Coturn, a free open source implementation of TURN and STUN Server. By sending a `CONNECT` request with the `XOR-PEER-ADDRESS` value of `0.0.0.0`, a malicious user can relay packets to the loopback interface, bypassing default access control protection. This can be achieved even when Coturn is listening on IPv6 by using either `[::1]` or `[::]` as the peer address. The estimated number of potentially affected devices worldwide is not specified. There is no information about real-world incidents where this issue was exploited. Recommendations: For Coturn versions prior to 4.5.2, update to version 4.5.2 or later to resolve the issue. As a temporary workaround, consider denying the addresses in the address block `0.0.0.0/8`, `[::1]`, and `[::]` by default unless `--allow-loopback-peers` has been specified. Additionally, administrators can specify `--denied-peer-ip=0.0.0.0` (or similar) to prevent malicious users from relaying packets to the loopback interface.