Subject: CVS commit: pkgsrc/comms/asterisk13
From: John Nemeth
Date: 2017-05-29 22:52:37
Message id: 20170529205237.D21FBFBE4@cvs.NetBSD.org

Log Message:
Add fixes for AST-2017-002, AST-2017-003, and AST-2017-004.  Note
that the first two don't affect pkgsrc as we are using chan_sip
not PJSIP.  The last only affects users of SCCP, which is Cisco's
proprietary protocol.

----- AST-2017-002

A remote crash can be triggered by sending a SIP packet to
Asterisk with a specially crafted CSeq header and a Via
header with no branch parameter. The issue is that the
PJSIP RFC 2543 transaction key generation algorithm does
not allocate a large enough buffer. By overrunning the
buffer, the memory allocation table becomes corrupted,
leading to an eventual crash.

This issue is in PJSIP, and so the issue can be fixed
without performing an upgrade of Asterisk at all. However,
we are releasing a new version of Asterisk with the bundled
PJProject updated to include the fix.

If you are running Asterisk with chan_sip, this issue does
not affect you.

----- AST-2017-003

The multi-part body parser in PJSIP contains a logical
error that can make certain multi-part body parts attempt
to read memory from outside the allowed boundaries. A
specially-crafted packet can trigger these invalid reads
and potentially induce a crash.

The issue is within the PJSIP project and not in Asterisk.
Therefore, the problem can be fixed without upgrading
Asterisk. However, we will be releasing a new version of
Asterisk where the bundled version of PJSIP has been
updated to have the bug patched.

If you are using Asterisk with chan_sip, this issue does
not affect you.

----- AST-2017-004

A remote memory exhaustion can be triggered by sending an
SCCP packet to Asterisk system with chan_skinny enabled
that is larger than the length of the SCCP header but
smaller than the packet length specified in the header. The
loop that reads the rest of the packet doesn't detect that
the call to read() returned end-of-file before the expected
number of bytes and continues infinitely. The partial
data message logging in that tight loop causes Asterisk to
exhaust all available memory.

Files:
RevisionActionfile
1.27modifypkgsrc/comms/asterisk13/Makefile
1.13modifypkgsrc/comms/asterisk13/distinfo