An issue was discovered in Asterisk through 19.x and Certified Asterisk through 16.8-cert13. The funcodbc module provides possibly inadequate escaping functionality for backslash characters in SQL queries, resulting in user-provided data creating a broken SQL query or possibly a SQL injection. This is fixed in 16.25.2, 18.11.2, and 19.3.2, and 16.8-cert14.

In Asterisk 11.x before 11.25.2, 13.x before 13.17.1, and 14.x before 14.6.1 and Certified Asterisk 11.x before 11.6-cert17 and 13.x before 13.13-cert5, unauthorized command execution is possible. The appminivm module has an "externnotify" program configuration option that is executed by the MinivmNotify dialplan application. The application uses the caller-id name and number as part of a built string passed to the OS shell for interpretation and execution. Since the caller-id name and number can come from an untrusted source, a crafted caller-id name or number allows an arbitrary shell command injection.

An SSRF issue was discovered in Asterisk through 19.x. When using STIR/SHAKEN, it's possible to send arbitrary requests (such as GET) to interfaces such as localhost by using the Identity header. This is fixed in 16.25.2, 18.11.2, and 19.3.2.

manager.c in the Manager Interface in Asterisk Open Source 1.4.x before 1.4.40.1, 1.6.1.x before 1.6.1.25, 1.6.2.x before 1.6.2.17.3, and 1.8.x before 1.8.3.3 and Asterisk Business Edition C.x.x before C.3.6.4 does not properly check for the system privilege, which allows remote authenticated users to execute arbitrary commands via an Originate action that has an Async header in conjunction with an Application header.

The DB dialplan function in Asterisk Open Source 1.8.x before 1.8.32, 11.x before 11.1.4.1, 12.x before 12.7.1, and 13.x before 13.0.1 and Certified Asterisk 1.8 before 1.8.28-cert8 and 11.6 before 11.6-cert8 allows remote authenticated users to gain privileges via a call from an external protocol, as demonstrated by the AMI protocol.

An Improper Neutralization of Special Elements used in an OS Command issue was discovered in Digium Asterisk GUI 2.1.0 and prior. An OS command injection vulnerability has been identified that may allow the execution of arbitrary code on the system through the inclusion of OS commands in the URL request of the program.

An issue was discovered in manager.c in Sangoma Asterisk through 13.x, 16.x, 17.x and Certified Asterisk 13.21 through 13.21-cert4. A remote authenticated Asterisk Manager Interface (AMI) user without system authorization could use a specially crafted Originate AMI request to execute arbitrary system commands.

A Buffer Overflow issue was discovered in Asterisk Open Source 13 before 13.18.1, 14 before 14.7.1, and 15 before 15.1.1 and Certified Asterisk 13.13 before 13.13-cert7. No size checking is done when setting the user field for Party B on a CDR. Thus, it is possible for someone to use an arbitrarily large string and write past the end of the user field storage buffer. NOTE: this is different from CVE-2017-7617, which was only about the Party A buffer.

Remote code execution can occur in Asterisk Open Source 13.x before 13.14.1 and 14.x before 14.3.1 and Certified Asterisk 13.13 before 13.13-cert3 because of a buffer overflow in a CDR user field, related to X-ClientCode in chansip, the CDR dialplan function, and the AMI Monitor action.

Asterisk is an open source private branch exchange and telephony toolkit. In Asterisk versions 18.20.0 and prior, 20.5.0 and prior, and 21.0.0; as well as ceritifed-asterisk 18.9-cert5 and prior, the 'update' functionality of the PJSIPHEADER dialplan function can exceed the available buffer space for storing the new value of a header. By doing so this can overwrite memory or cause a crash. This is not externally exploitable, unless dialplan is explicitly written to update a header based on data from an outside source. If the 'update' functionality is not used the vulnerability does not occur. A patch is available at commit a1ca0268254374b515fa5992f01340f7717113fa.

Unspecified vulnerability in the SIP channel driver (channels/chansip.c) in Asterisk 1.2.x before 1.2.13 and 1.4.x before 1.4.0-beta3 allows remote attackers to cause a denial of service (resource consumption) via unspecified vectors that result in the creation of "a real pvt structure" that uses more resources than necessary.

The IAX2 channel driver (chaniax2) in Asterisk Open 1.2.x before 1.2.23, 1.4.x before 1.4.9, and Asterisk Appliance Developer Kit before 0.6.0, when configured to allow unauthenticated calls, allows remote attackers to cause a denial of service (resource exhaustion) via a flood of calls that do not complete a 3-way handshake, which causes an astchannel to be allocated but not released.

The SIP channel driver in Asterisk Open Source 1.2.x before 1.2.34, 1.4.x before 1.4.26.1, 1.6.0.x before 1.6.0.12, and 1.6.1.x before 1.6.1.4; Asterisk Business Edition A.x.x, B.x.x before B.2.5.9, C.2.x before C.2.4.1, and C.3.x before C.3.1; and Asterisk Appliance s800i 1.2.x before 1.3.0.3 does not use a maximum width when invoking sscanf style functions, which allows remote attackers to cause a denial of service (stack memory consumption) via SIP packets containing large sequences of ASCII decimal characters, as demonstrated via vectors related to (1) the CSeq value in a SIP header, (2) large Content-Length value, and (3) SDP.

Asterisk 1.4 before 1.4.1 and 1.2 before 1.2.16 allows remote attackers to cause a denial of service (crash) by sending a Session Initiation Protocol (SIP) packet without a URI and SIP-version header, which results in a NULL pointer dereference.

An issue was discovered in Asterisk through 19.x. When using STIR/SHAKEN, it is possible to download files that are not certificates. These files could be much larger than what one would expect to download, leading to Resource Exhaustion. This is fixed in 16.25.2, 18.11.2, and 19.3.2.

Buffer overflow in the getmsgtext of chansip.c in the Session Initiation Protocol (SIP) protocol implementation for Asterisk releases before August 15, 2003, allows remote attackers to execute arbitrary code via certain (1) MESSAGE or (2) INFO requests.

SQL injection vulnerability in the Call Detail Record (CDR) logging functionality for Asterisk allows remote attackers to execute arbitrary SQL via a CallerID string.

Stack-based buffer overflow in channels/chanmgcp.c in MGCP in Asterisk 1.0 through 1.2.10 allows remote attackers to execute arbitrary code via a crafted audit endpoint (AUEP) response.

Asterisk 1.2.10 supports the use of client-controlled variables to determine filenames in the Record function, which allows remote attackers to (1) execute code via format string specifiers or (2) overwrite files via directory traversals involving unspecified vectors, as demonstrated by the CALLERIDNAME variable.

Integer overflow in the getinput function in the Skinny channel driver (chanskinny.c) in Asterisk 1.0.x before 1.0.12 and 1.2.x before 1.2.13, as used by Cisco SCCP phones, allows remote attackers to execute arbitrary code via a certain dlen value that passes a signed integer comparison and leads to a heap-based buffer overflow.

The IAX2 channel driver (chaniax2) for Asterisk 1.2.x before 1.2.9 and 1.0.x before 1.0.11 allows remote attackers to cause a denial of service (crash) and execute arbitrary code via truncated IAX 2 (IAX2) video frames, which bypasses a length check and leads to a buffer overflow involving negative length check. NOTE: the vendor advisory claims that only a DoS is possible, but the original researcher is reliable.

Stack-based buffer overflow in the astparsedigest function in main/utils.c in Asterisk 1.8.x before 1.8.10.1 and 10.x before 10.2.1 allows remote attackers to cause a denial of service (crash) or possibly execute arbitrary code via a long string in an HTTP Digest Authentication header.

main/http.c in Asterisk Open Source 1.8.x before 1.8.26.1, 11.8.x before 11.8.1, and 12.1.x before 12.1.1, and Certified Asterisk 1.8.x before 1.8.15-cert5 and 11.6 before 11.6-cert2, allows remote attackers to cause a denial of service (stack consumption) and possibly execute arbitrary code via an HTTP request with a large number of Cookie headers.

The respjsipacl module in Asterisk Open Source 12.x before 12.7.1 and 13.x before 13.0.1 does not properly create and load ACLs defined in pjsip.conf at startup, which allows remote attackers to bypass intended PJSIP ACL rules.

A Buffer Overflow issue was discovered in Asterisk through 13.19.1, 14.x through 14.7.5, and 15.x through 15.2.1, and Certified Asterisk through 13.18-cert2. When processing a SUBSCRIBE request, the respjsippubsub module stores the accepted formats present in the Accept headers of the request. This code did not limit the number of headers it processed, despite having a fixed limit of 32. If more than 32 Accept headers were present, the code would write outside of its memory and cause a crash.

A NULL pointer access issue was discovered in Asterisk 15.x through 15.2.1. The RTP support in Asterisk maintains its own registry of dynamic codecs and desired payload numbers. While an SDP negotiation may result in a codec using a different payload number, these desired ones are still stored internally. When an RTP packet was received, this registry would be consulted if the payload number was not found in the negotiated SDP. This registry was incorrectly consulted for all packets, even those which are dynamic. If the payload number resulted in a codec of a different type than the RTP stream (for example, the payload number resulted in a video codec but the stream carried audio), a crash could occur if no stream of that type had been negotiated. This was due to the code incorrectly assuming that a stream of that type would always exist.

There is a stack consumption vulnerability in the reshttpwebsocket.so module of Asterisk through 13.23.0, 14.7.x through 14.7.7, and 15.x through 15.6.0 and Certified Asterisk through 13.21-cert2. It allows an attacker to crash Asterisk via a specially crafted HTTP request to upgrade the connection to a websocket.

In res/resrtpasterisk.c in Asterisk 11.x before 11.25.2, 13.x before 13.17.1, and 14.x before 14.6.1 and Certified Asterisk 11.x before 11.6-cert17 and 13.x before 13.13-cert5, unauthorized data disclosure (media takeover in the RTP stack) is possible with careful timing by an attacker. The "strictrtp" option in rtp.conf enables a feature of the RTP stack that learns the source address of media for a session and drops any packets that do not originate from the expected address. This option is enabled by default in Asterisk 11 and above. The "nat" and "rtpsymmetric" options (for chansip and chanpjsip, respectively) enable symmetric RTP support in the RTP stack. This uses the source address of incoming media as the target address of any sent media. This option is not enabled by default, but is commonly enabled to handle devices behind NAT. A change was made to the strict RTP support in the RTP stack to better tolerate late media when a reinvite occurs. When combined with the symmetric RTP support, this introduced an avenue where media could be hijacked. Instead of only learning a new address when expected, the new code allowed a new source address to be learned at all times. If a flood of RTP traffic was received, the strict RTP support would allow the new address to provide media, and (with symmetric RTP enabled) outgoing traffic would be sent to this new address, allowing the media to be hijacked. Provided the attacker continued to send traffic, they would continue to receive traffic as well.

In the pjsip channel driver (respjsip) in Asterisk 13.x before 13.17.1 and 14.x before 14.6.1, a carefully crafted tel URI in a From, To, or Contact header could cause Asterisk to crash.

An issue was discovered in Sangoma Asterisk 13.x before 13.38.3, 16.x before 16.19.1, 17.x before 17.9.4, and 18.x before 18.5.1, and Certified Asterisk before 16.8-cert10. If the IAX2 channel driver receives a packet that contains an unsupported media format, a crash can occur.