[asterisk-users] Asterisk 11.25.1, 13.13.1, 14.2.1, 11.6-cert16, and 13.8-cert4 Now Available (Security Release)

[Asterisk Development Team]

The Asterisk Development Team has announced security releases for Asterisk
11, 13, 14, and Certified Asterisk 11.6 and 13.8. The available
security releases are released as versions 11.25.1, 13.13.1, 14.2.1,
11.6-cert16, and 13.8-cert4.

These releases are available for immediate download at:

http://downloads.asterisk.org/pub/telephony/asterisk/releases
http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/

The release of versions 13.13.1 and 14.2.1 resolve the following security
vulnerability:

* AST-2016-008: Crash on SDP offer or answer from endpoint using Opus

  If an SDP offer or answer is received with the Opus codec and with the
format
  parameters separated using a space the code responsible for parsing will
  recursively call itself until it crashes. This occurs as the code does not
  properly handle spaces separating the parameters.

  This does NOT require the endpoint to have Opus configured in Asterisk.
This
  also does not require the endpoint to be authenticated. If guest is
enabled
  for chan_sip or anonymous in chan_pjsip an SDP offer or answer is still
  processed and the crash occurs.

The release of versions 11.25.1, 13.13.1, 14.2.1, 11.6-cert16 and 13.8-cert4
resolve the following security vulnerability:

* AST-2016-009: Remote unauthenticated sessions in chan_sip

  The chan_sip channel driver has a liberal definition for whitespace when
  attempting to strip the content between a SIP header name and a colon
  character. Rather than following RFC 3261 and stripping only spaces and
  horizontal tabs, Asterisk treats any non-printable ASCII character as if
it
  were whitespace. This means that headers such as

                 Contact\x01:

  will be seen as a valid Contact header.

  This mostly does not pose a problem until Asterisk is placed in tandem
with
  an authenticating SIP proxy. In such a case, a crafty combination of valid
  and invalid To headers can cause a proxy to allow an INVITE request into
  Asterisk without authentication since it believes the request is an
in-dialog
  request. However, because of the bug described above, the request will
look
  like an out-of-dialog request to Asterisk. Asterisk will then process the
  request as a new call. The result is that Asterisk can process calls from
  unvetted sources without any authentication.

  If you do not use a proxy for authentication, then this issue does not
affect
  you. If your proxy is dialog-aware (meaning that the proxy keeps track of
what
  dialogs are currently valid), then this issue does not affect you. If you
use
  chan_pjsip instead of chan_sip, then this issue does not affect you.

For a full list of changes in the current releases, please see the
ChangeLogs:

http://downloads.asterisk.org/pub/telephony/asterisk/release
s/ChangeLog-11.25.1
http://downloads.asterisk.org/pub/telephony/asterisk/release
s/ChangeLog-13.13.1
http://downloads.asterisk.org/pub/telephony/asterisk/release
s/ChangeLog-14.2.1
http://downloads.asterisk.org/pub/telephony/certified-asteri
sk/releases/ChangeLog-certified-11.6-cert16
http://downloads.asterisk.org/pub/telephony/certified-asteri
sk/releases/ChangeLog-certified-13.8-cert4

The security advisories are available at:

 * http://downloads.asterisk.org/pub/security/AST-2016-008.pdf
 * http://downloads.asterisk.org/pub/security/AST-2016-009.pdf

Thank you for your continued support of Asterisk!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20161208/7e7f56cf/attachment.html>