Bugzilla Bug 135680

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