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 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.
Upstream:released (1:13.17.1~dfsg-1)
Ubuntu 12.04 ESM (Precise Pangolin):DNE
Ubuntu 14.04 ESM (Trusty Tahr):DNE (trusty was needed)
Ubuntu 16.04 LTS (Xenial Xerus):needed
Ubuntu 18.04 LTS (Bionic Beaver):not-affected (1:13.17.1~dfsg-1ubuntu1)
Ubuntu 19.10 (Eoan Ermine):not-affected (1:13.17.1~dfsg-1ubuntu1)
Ubuntu 20.04 (Focal Fossa):not-affected (1:13.17.1~dfsg-1ubuntu1)
Introduced by
Fixed by
More Information

Updated: 2020-04-24 03:37:27 UTC (commit d3f8a6ed481830fb100109a132bef581fc4176fe)