Insufficient RTCP packet validation could allow reading
stale buffer contents and when combined with the â€œnatâ€ and
â€œsymmetric_rtpâ€ options allow redirecting where Asterisk
sends the next RTCP report.

The RTP stream qualification to learn the source address of
media always accepted the first RTP packet as the new
source and allowed what AST-2017-005 was mitigating. The
intent was to qualify a series of packets before accepting
the new source address.

Resolution The RTP/RTCP stack will now validate RTCP packets before
processing them. Packets failing validation are discarded.
RTP stream qualification now requires the intended series of
packets from the same address without seeing packets from a
different source address to accept a new source address.

This document may be superseded by later versions; if so, the latest
version will be posted at
http://downloads.digium.com/pub/security/AST-2017-008.pdf and
http://downloads.digium.com/pub/security/AST-2017-008.html

Product Asterisk
Summary Remote Crash Vulerability in res_pjsip
Nature of Advisory Denial of Service
Susceptibility Remote Unauthenticated Sessions
Severity Moderate
Exploits Known No
Reported On August 30, 2017
Reported By Ross Beer
Posted On
Last Updated On August 30, 2017
Advisory Contact George Joseph
CVE Name

Description A carefully crafted URI in a From, To or Contact header
could cause Asterisk to crash.

Description The app_minivm module has an â€œexternnotifyâ€ program
configuration option that is executed by the MinivmNotify
dialplan application. The application uses the caller-id
name and number as part of a built string passed to the OS
shell for interpretation and execution. Since the caller-id
name and number can come from an untrusted source, a
crafted caller-id name or number allows an arbitrary shell
command injection.

Resolution Patched Asteriskâ€™s app_minivm module to use a different
system call that passes argument strings in an array instead
of having the OS shell determine the application parameter
boundaries.

This document may be superseded by later versions; if so, the latest
version will be posted at
http://downloads.digium.com/pub/security/AST-2017-006.pdf and
http://downloads.digium.com/pub/security/AST-2017-006.html

Description The "strictrtp" option in rtp.conf enables a feature of the
RTP stack that learns the source address of media for a
session and drops any packets that do not originate from
the expected address. This option is enabled by default in
Asterisk 11 and above.

The "nat" and "rtp_symmetric" options for chan_sip and
chan_pjsip respectively enable symmetric RTP support in the
RTP stack. This uses the source address of incoming media
as the target address of any sent media. This option is not
enabled by default but is commonly enabled to handle
devices behind NAT.

A change was made to the strict RTP support in the RTP
stack to better tolerate late media when a reinvite occurs.
When combined with the symmetric RTP support this
introduced an avenue where media could be hijacked. Instead
of only learning a new address when expected the new code
allowed a new source address to be learned at all times.

If a flood of RTP traffic was received the strict RTP
support would allow the new address to provide media and
with symmetric RTP enabled outgoing traffic would be sent
to this new address, allowing the media to be hijacked.
Provided the attacker continued to send traffic they would
continue to receive traffic as well.

Resolution The RTP stack will now only learn a new source address if it
has been told to expect the address to change. The RTCP
support has now also been updated to drop RTCP reports that
are not regarding the RTP session currently in progress. The
strict RTP learning progress has also been improved to guard
against a flood of RTP packets attempting to take over the
media stream.

This document may be superseded by later versions; if so, the latest
version will be posted at
http://downloads.digium.com/pub/security/AST-2017-005.pdf and
http://downloads.digium.com/pub/security/AST-2017-005.html

It is with great pleasure I wish to inform the world of the first beta release of the new Asterisk 15 branch. It’s a very exciting time to be a user of Asterisk! Asterisk 15 is arguably the biggest release of Asterisk that has happened in the last 10 or so years. There has been a lot of work done in the Asterisk core to better support newer multi-stream video and WebRTC related technologies. For those who are interested, much of this will be covered in blog posts over the next month or two.

Typically, when a new major branch of Asterisk is created (13, 14, 15…), there are a few months of testing on the new branch that occurs prior to release in order to find regressions and other issues that may cause a first official release from the branch to be dead on arrival for a significant number of users. With today’s release of 15.0.0-beta1, this process has begun. Please feel free to start testing this version of Asterisk in as many adverse environments as possible. Any bugs should be reported on the Asterisk issue tracker at https://issues.asterisk.org/

As a side note, due to many of the core changes in the 15 branch that have been made since Asterisk 14 was released, it has been decided that Asterisk 15 will not be an LTS release. For those of you who are not familiar with the differences between LTS versus standard releases, you can find more information here.

Thanks to all the many Asterisk community members for providing so much help and support to make Asterisk the great open source project that it is.

Product Asterisk
Summary Memory exhaustion on short SCCP packets
Nature of Advisory Denial of Service
Susceptibility Remote Unauthenticated Sessions
Severity Critical
Exploits Known No
Reported On April 13, 2017
Reported By Sandro Gauci
Posted On
Last Updated On April 13, 2017
Advisory Contact George Joseph <gjoseph AT digium DOT com>
CVE Name

Description 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.

Resolution If support for the SCCP protocol is not required, remove or
disable the module.

If support for SCCP is required, an upgrade to Asterisk will
be necessary.

Description 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.

Resolution We have submitted the error report to the PJProject
maintainers and have coordinated a release...........

Description 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.

Resolution A patch created by the Asterisk team has been submitted and
accepted by the PJProject maintainers.