From oss-security at $URL:
Arches, please test and mark stable:
Target KEYWORDS="amd64 x86"
I'm not sure if this is the correct place to write this, but Asterisk works fine on ppc and ppc64 as well after unmasking. We've been using source-compiled 1.4 for a while, but recently moved on to the 1.8 ebuilds, without any errors.
(In reply to comment #3)
> I'm not sure if this is the correct place to write this, but Asterisk works
> fine on ppc and ppc64 as well after unmasking. We've been using
> source-compiled 1.4 for a while, but recently moved on to the 1.8 ebuilds,
> without any errors.
Do not attempt to hijack bugs, especially not security bugs.
Archtested on X86: Everything OK.
1) Compiles successfully with various USE-flags.
2) All rdeps compile successfully.
3) No repoman errors reported.
4) I do not have a voip phone but, per ago, I was able to verify the stability of the net-misc/asterisk-22.214.171.124 daemon and it's utilities. I also witnessed no errors of concern in asterisk's log file.
x86 stable, thanks Dan.
@security, please check the severity and file glsa request.
Thanks, everyone. GLSA is already drafted and ready for review.
chan_sip.c in the SIP channel driver in Asterisk Open Source 1.8.x before
126.96.36.199 and 10.x before 10.3.1 and Asterisk Business Edition C.3.x before
C.3.7.4, when the trustrpid option is enabled, allows remote authenticated
users to cause a denial of service (daemon crash) by sending a SIP UPDATE
message that triggers a connected-line update attempt without an associated
Heap-based buffer overflow in chan_skinny.c in the Skinny channel driver in
Asterisk Open Source 1.6.2.x before 188.8.131.52, 1.8.x before 184.108.40.206, and
10.x before 10.3.1 allows remote authenticated users to cause a denial of
service or possibly have unspecified other impact via a series of
main/manager.c in the Manager Interface in Asterisk Open Source 1.6.2.x
before 220.127.116.11, 1.8.x before 18.104.22.168, and 10.x before 10.3.1 and Asterisk
Business Edition C.3.x before C.3.7.4 does not properly enforce System class
authorization requirements, which allows remote authenticated users to
execute arbitrary commands via (1) the originate action in the MixMonitor
application, (2) the SHELL and EVAL functions in the GetVar manager action,
or (3) the SHELL and EVAL functions in the Status manager action.
This issue was resolved and addressed in
GLSA 201206-05 at http://security.gentoo.org/glsa/glsa-201206-05.xml
by GLSA coordinator Sean Amoss (ackle).