http://downloads.asterisk.org/pub/security/AST-2014-019.html
From $[URL}: When handling a WebSocket frame the res_http_websocket module dynamically changes the size of the memory used to allow the provided payload to fit. If a payload length of zero was received the code would incorrectly attempt to resize to zero. This operation would succeed and end up freeing the memory but be treated as a failure. When the session was subsequently torn down this memory would get freed yet again causing a crash.
+*asterisk-12.7.2 (16 Dec 2014) +*asterisk-11.14.2 (16 Dec 2014) + + 16 Dec 2014; Tony Vroon <chainsaw@gentoo.org> +asterisk-11.14.2.ebuild, + -asterisk-12.7.1.ebuild, +asterisk-12.7.2.ebuild: + Incorrect and unsafe memory handling (AST-2014-019) in res_http_websocket + addressed in both branches, vulnerable non-stable ebuilds removed. For + security bug #532242. Enable MeetMe conference support if DAHDI is enabled, + as requested by Kristian Fiskerstrand in bug #531486. Arches, please test & mark stable: =net-misc/asterisk-11.14.2 Please test with USE="samples" and take the daemon through three stop/start cycles.
Changing rating to B3, for some reason I didn't remember this is indeed a stable package.
amd64 stable
x86 stable. Maintainer(s), please cleanup. Security, please vote.
+ 22 Dec 2014; Tony Vroon <chainsaw@gentoo.org> -asterisk-11.14.1.ebuild, + +asterisk-11.15.0.ebuild, +asterisk-12.8.0.ebuild: + Remove vulnerable stable ebuild for security bug #532242. Add newer ebuilds + on both branches which contain primarily crash fixes.
GLSA vote: yes
CVE-2014-9374 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2014-9374): Double free vulnerability in the WebSocket Server (res_http_websocket module) in Asterisk Open Source 11.x before 11.14.2, 12.x before 12.7.2, and 13.x before 13.0.2 and Certified Asterisk 11.6 before 11.6-cert9 allows remote attackers to cause a denial of service (crash) by sending a zero length frame after a non-zero length frame.
GLSA Vote: Yes Created new GLSA request
This issue was resolved and addressed in GLSA 201412-51 at http://security.gentoo.org/glsa/glsa-201412-51.xml by GLSA coordinator Kristian Fiskerstrand (K_F).
