Randell Jesup and the Firefox team discovered that srtp, Cisco's reference implementation of the Secure Real-time Transport Protocol (SRTP), does not properly handle RTP header CSRC count and extension header length. A remote attacker can exploit this vulnerability to crash an application linked against libsrtp, resulting in a denial of service. References: http://seclists.org/bugtraq/2016/Apr/11
Created libsrtp tracking bugs for this issue: Affects: fedora-all [bug 1323703] Affects: epel-6 [bug 1323704] Affects: epel-7 [bug 1323705]
Debian patch: https://sources.debian.net/src/srtp/1.4.5~20130609~dfsg-1.2/debian/patches/CVE-2015-6360.patch/ Upstream patch: https://github.com/cisco/libsrtp/commit/704a31774db0dd941094fd2b47c21638b8dc3de2 Other upstream patches mentioned: https://github.com/cisco/libsrtp/commit/be95365fbb4788b688cab7af61c65b7989055fb4 https://github.com/cisco/libsrtp/commit/be06686c8e98cc7bd934e10abb6f5e971d03f8ee https://github.com/cisco/libsrtp/commit/cdc69f2acde796a4152a250f869271298abc233f
asterisk-1.8.32.3-2.el6, libsrtp-1.5.4-3.el6, pjproject-2.3-7.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
Was it necessary to bump the libsrtp.so name to libsrtp.so.1 in this update?
That's the soname for the 1.5 series from upstream, so yes.
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2020:3873 https://access.redhat.com/errata/RHSA-2020:3873