Asterisk upstream published following security advisory AST-2008-006: Javantea originally reported an issue in IAX2, whereby an attacker could send a spoofed IAX2 NEW message, and Asterisk would start sending early audio to the target address, without ever receiving an initial response. That original vulnerability was addressed in June 2007, by requiring a response to the initial NEW message before starting to send any audio. Javantea subsequently found that we were doing insufficent verification of the ACK response and that the ACK response could be spoofed, just like the initial NEW message. We have addressed this failure with two changes. First, we have started to require that the ACK response contains the unique source call number that we send in our reply to the NEW message. Any ACK response that does not contain the source call number that we have created will be silently thrown away. Second, we have made the generation of our source call number a little more difficult to predict, by randomly selecting a source call number, instead of allocating them sequentially. Fixed in: 1.4.19.1 References: http://downloads.digium.com/pub/security/AST-2008-006.html
asterisk-1.4.19.1-1.fc8 has been submitted as an update for Fedora 8
asterisk-1.4.19.1-1.fc7 has been submitted as an update for Fedora 7
CVE ids assigned by Mitre: CVE-2008-1923: The IAX2 channel driver (chan_iax2) in Asterisk 1.2 before revision 72630 and 1.4 before revision 65679, when configured to allow unauthenticated calls, sends "early audio" to an unverified source IP address of a NEW message, which allows remote attackers to cause a denial of service (traffic amplification) via a spoofed NEW message. CVE-2008-1897: The IAX2 channel driver (chan_iax2) in Asterisk Open Source 1.0.x, 1.2.x before 1.2.28, and 1.4.x before 1.4.19.1; Business Edition A.x.x, B.x.x before B.2.5.2, and C.x.x before C.1.8.1; AsteriskNOW before 1.0.3; Appliance Developer Kit 0.x.x; and s800i before 1.1.0.3, when configured to allow unauthenticated calls, does not verify that an ACK response contains a call number matching the server's reply to a NEW message, which allows remote attackers to cause a denial of service (traffic amplification) via a spoofed ACK response that does not complete a 3-way handshake. NOTE: this issue exists because of an incomplete fix for CVE-2008-1923. References: http://www.altsci.com/concepts/page.php?s=asteri&p=1 http://bugs.digium.com/view.php?id=10078
asterisk-1.4.19.1-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
asterisk-1.4.19.1-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
This issue was addressed in: Fedora: https://admin.fedoraproject.org/updates/F7/FEDORA-2008-3365 https://admin.fedoraproject.org/updates/F8/FEDORA-2008-3390