Asterisk is an open source private branch exchange (PBX) and telephony toolkit. Prior to asterisk versions 18.24.2, 20.9.2, and 21.4.2 and certified-asterisk versions 18.9-cert11 and 20.7-cert2, an AMI user with `write=originate` may change all configuration files in the `/etc/asterisk/` directory. This occurs because they are able to curl remote files and write them to disk, but are also able to append to existing files using the `FILE` function inside the `SET` application. This issue may result in privilege escalation, remote code execution and/or blind server-side request forgery with arbitrary protocol. Asterisk versions 18.24.2, 20.9.2, and 21.4.2 and certified-asterisk versions 18.9-cert11 and 20.7-cert2 contain a fix for this issue.

Asterisk is an open source private branch exchange and telephony toolkit. In Asterisk prior to versions 18.20.1, 20.5.1, and 21.0.1; as well as certified-asterisk prior to 18.9-cert6; Asterisk is susceptible to a DoS due to a race condition in the hello handshake phase of the DTLS protocol when handling DTLS-SRTP for media setup. This attack can be done continuously, thus denying new DTLS-SRTP encrypted calls during the attack. Abuse of this vulnerability may lead to a massive Denial of Service on vulnerable Asterisk servers for calls that rely on DTLS-SRTP. Commit d7d7764cb07c8a1872804321302ef93bf62cba05 contains a fix, which is part of versions 18.20.1, 20.5.1, 21.0.1, amd 18.9-cert6.

Asterisk is an open source private branch exchange and telephony toolkit. In Asterisk prior to versions 18.20.1, 20.5.1, and 21.0.1, as well as certified-asterisk prior to 18.9-cert6, it is possible to read any arbitrary file even when the `live_dangerously` is not enabled. This allows arbitrary files to be read. Asterisk versions 18.20.1, 20.5.1, and 21.0.1, as well as certified-asterisk prior to 18.9-cert6, contain a fix for this issue.

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 PJSIP_HEADER 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.

An 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. A memory leak occurs when an Asterisk pjsip session object is created and that call gets rejected before the session itself is fully established. When this happens the session object never gets destroyed. Eventually Asterisk can run out of memory and crash.

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.

In Asterisk 11.x before 11.25.3, 13.x before 13.17.2, and 14.x before 14.6.2 and Certified Asterisk 11.x before 11.6-cert18 and 13.x before 13.13-cert6, insufficient RTCP packet validation could allow reading stale buffer contents and when combined with the "nat" and "symmetric_rtp" options allow redirecting where Asterisk sends the next RTCP report.

In res/res_rtp_asterisk.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 "rtp_symmetric" options (for chan_sip and chan_pjsip, 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 symmet…

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 app_minivm 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.

PJSIP, as used in Asterisk Open Source 13.x before 13.15.1 and 14.x before 14.4.1, Certified Asterisk 13.13 before 13.13-cert4, and other products, allows remote attackers to cause a denial of service (buffer overflow and application crash) via a SIP packet with a crafted CSeq header in conjunction with a Via header that lacks a branch parameter.