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 <email@example.com> +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:
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.
Maintainer(s), please cleanup.
Security, please vote.
+ 22 Dec 2014; Tony Vroon <firstname.lastname@example.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
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).