There are two new Asterisk security advisories. http://downloads.asterisk.org/pub/security/AST-2011-005.html Description On systems that have the Asterisk Manager Interface, Skinny, SIP over TCP, or the built in HTTP server enabled, it is possible for an attacker to open as many connections to asterisk as he wishes. This will cause Asterisk to run out of available file descriptors and stop processing any new calls. Additionally, disk space can be exhausted as Asterisk logs failures to open new file descriptors. http://downloads.digium.com/pub/security/AST-2011-006.html Description It is possible for a user of the Asterisk Manager Interface to bypass a security check and execute shell commands when they should not have that ability. Sending the "Async" header with the "Application" header during an Originate action, allows authenticated manager users to execute shell commands. Only users with the "system" privilege should be able to do this.
+*asterisk-1.8.3.3 (26 Apr 2011) + + 26 Apr 2011; Tony Vroon <chainsaw@gentoo.org> -asterisk-1.8.3.2.ebuild, + +asterisk-1.8.3.3.ebuild: + Update in 1.8 branch for AST-2011-005 & AST-2011-006 (resource exhaustion & + unauthenticated shell access, respectively). Remove vulnerable ebuild.
+*asterisk-1.6.2.17.3 (26 Apr 2011) + + 26 Apr 2011; Tony Vroon <chainsaw@gentoo.org> +asterisk-1.6.2.17.3.ebuild: + Update in 1.6.2 branch for security bug #364887 by Tim Sammut. Addresses + CVE-2011-1507 (AST-2011-005/AST-2011-006) and is planned for fast-track + stabilisation. Arches, please test & stable net-misc/asterisk-1.6.2.17.3; this should not introduce additional dependencies over 1.6.2.17.2 and there are no changes to the patchset. If you are able to repeatedly start & stop the daemon using the init script (on the default config), that constitutes a successful arch test. Could the last arch please delete the vulnerable 1.6.2.17.2 ebuild from the tree.
@x86 team net-misc/dahdi-2.4.0 does not build with 2.6.37 so please test also: =net-misc/dahdi-2.4.1 =net-misc/dahdi-tools-2.4.1 @amd64 works for me asterisk dahdi dahdi-tools. You can stabilize all.
+ 26 Apr 2011; Tony Vroon <chainsaw@gentoo.org> dahdi-2.4.1.ebuild: + Fast-track AMD64 stable for security bug #364887. Testing by Agostino "ago" + Sarubbo. + 26 Apr 2011; Tony Vroon <chainsaw@gentoo.org> dahdi-tools-2.4.1.ebuild: + Fast-track AMD64 stable for security bug #364887. Testing by Agostino "ago" + Sarubbo. + 26 Apr 2011; Tony Vroon <chainsaw@gentoo.org> asterisk-1.6.2.17.3.ebuild: + Make dependency on newer DAHDI explicit to avoid surprises for the X86 team. + 26 Apr 2011; Tony Vroon <chainsaw@gentoo.org> asterisk-1.6.2.17.3.ebuild: + Mark stable on AMD64 for security bug #364887. Arch testing by Agostino "ago" + Sarubbo.
removing amd64 from CC then
I successfully tested the three packages here on x86. The only things i've seen are Bug 321979 and Bug 297995, which are no regressions but still true.
x86 stable. Thanks Andreas
+ 28 Apr 2011; Tony Vroon <chainsaw@gentoo.org> -asterisk-1.6.2.17.2.ebuild: + Removed vulnerable ebuild for CVE-2011-{1507,1599}, security bug #364887. Security, please proceed with GLSA vote.
Vote: YES.
GLSA Vote: Yes, too. Added to existing GLSA request.
CVE-2011-1599 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1599): manager.c in the Manager Interface in Asterisk Open Source 1.4.x before 1.4.40.1, 1.6.1.x before 1.6.1.25, 1.6.2.x before 1.6.2.17.3, and 1.8.x before 1.8.3.3 and Asterisk Business Edition C.x.x before C.3.6.4 does not properly check for the system privilege, which allows remote authenticated users to execute arbitrary commands via an Originate action that has an Async header in conjunction with an Application header. CVE-2011-1507 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-1507): Asterisk Open Source 1.4.x before 1.4.40.1, 1.6.1.x before 1.6.1.25, 1.6.2.x before 1.6.2.17.3, and 1.8.x before 1.8.3.3 and Asterisk Business Edition C.x.x before C.3.6.4 do not restrict the number of unauthenticated sessions to certain interfaces, which allows remote attackers to cause a denial of service (file descriptor exhaustion and disk space exhaustion) via a series of TCP connections.
This issue was resolved and addressed in GLSA 201110-21 at http://security.gentoo.org/glsa/glsa-201110-21.xml by GLSA coordinator Tim Sammut (underling).