An iax vulnerability was discovered in all asterisk versions. Asterisk 1.2.9 will be released soon with the fixes. All versions of iax affected. The details have not been posted yet and should be out tomorrow sometime, this is early notice so people can be ready to update and fix. in #asterisk-dev: (15:50:48) squinky86: kpfleming: what versions of asterisk does the iax vuln affect? I need to know what boxes to update or where to find details about the vulnerability. (15:50:58) kpfleming: all of them (15:51:11) kpfleming: the vulnerability details have not been posted yet, will go out tomorrow i suspect
Asterisk 1.2.9/1.0.11 is available for download
voip please provide an updated ebuild.
I can't find the full report, but this will need a glsa. In asterisk 1.0.11, the only thing that changed is chan_iax2, and in 1.2.9, only chan_iax2 and app_queue were changed, so this should be a simple version bump. Information: from the changelogs: "A security vulnerability that could lead to denial of service attacks and Asterisk process crashes was fixed in this release." "ensure that the received number of bytes is included in all IAX2 incoming frame analysis checks (fixes a known vulnerability)" And from asterisk.org: "The vulnerability affects all users with IAX2 clients that might be compromised or used by a malicious user, and can lead to denial of service attacks and random Asterisk server crashes via a relatively trivial exploit."
I rated it B1?(major) for now wich will for sure result in a GLSA publication if I didn't misunderstand the impact drastically.
asterisk 1.2.9.1 and 1.0.11.1 were released. "A bug in the vulnerability fix in the last release could cause Asterisk to improperly reject incoming video frames and result in deadlocks."
Asterisk-1.2.9_p1 and 1.0.11_p1 have been added to the main tree. I'm going to remove the affected 1.2.x ebuild(s) now. Older 1.2.x versions will still be available from the gentoo-voip overlay with the backported fix. Please mark 1.0.11_p1 stable, i'll remove the affected 1.0.x ebuilds after that. If you have the time, please mark the latest 1.0.x versions of libpri and zaptel stable too. Btw. i haven't gotten a notification mail from bugzilla after the voip@ CC has been added, did something change there?
Thanks Stefan. Arches please test and mark stable.
Remote code execution seems to be confirmed.
we are going to need the following stabilized as well: zaptel-1.0.10 on x86 ppc amd64 libpri-1.0.9-r2 on x86 ppc amd64 sparc i can take care of these for x86.
zaptel-1.0.10-r1 stable on x86. libpri-1.0.9-r2 stable on x86. asterisk-1.0.11_p1 stable on x86. 1.2 branch still needs x86 attention from the x86 herd or stkn.
Someone did a revbumpstable that sent sparc into the stable domain directly *SMACK* It works, but please next time please DO check the keywords and don't assume things.
rajiv, why do those need to go stable on amd64? There is no vulnerability in those packages, no libpri or zaptel package was ever stable amd64, and asterisk is not stable on amd64 due to multilib problems (fixed in asterisk 1.4, not released yet though).
asterisk wasn't stable on ppc before and I don't have the necessary hardware to confirm if it's working as expected or not. Therefore I see no reason why ppc should stable asterisk _now_. Removing us from CC.
amd64 has no stable versions of the listed packages and cannot mark most stable due to unstandard Makefiles. These have been fixed by the asterisk 1.4 build system (not back-portable at this time), so we will be eager to mark that version stable when the time comes.
(In reply to comment #9, comment #12, comment #13, comment #14) sorry about that, i'm not sure what i was thinking. libpri and zaptel do _not_ need to be marked stable on amd64 or ppc. at this point all the 1.0.x ebuilds of asterisk, libpri, and zaptel are ready to go.
Thx everyone. GLSA 200606-15