svn commit: r428237 - head/security/vuxml

Fri Dec 9 19:44:13 UTC 2016

Author: madpilot
Date: Fri Dec  9 19:44:11 2016
New Revision: 428237
URL: https://svnweb.freebsd.org/changeset/ports/428237

Log:
  Document vulnerabilities in net/asterisk11 and net/asterisk13.

Modified:
  head/security/vuxml/vuln.xml

Modified: head/security/vuxml/vuln.xml
==============================================================================

--- head/security/vuxml/vuln.xml	Fri Dec  9 19:30:19 2016	(r428236)
+++ head/security/vuxml/vuln.xml	Fri Dec  9 19:44:11 2016	(r428237)
@@ -58,6 +58,92 @@ Notes:
   * Do not forget port variants (linux-f10-libxml2, libxml2, etc.)
 -->
 <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">
+  <vuln vid="c0b13887-be44-11e6-b04f-001999f8d30b">
+    <topic>asterisk -- Authentication Bypass</topic>
+    <affects>
+      <package>
+	<name>asterisk11</name>
+	<range><lt>11.25.1</lt></range>
+      </package>
+      <package>
+	<name>asterisk13</name>
+	<range><lt>13.13.1</lt></range>
+      </package>
+    </affects>
+    <description>
+      <body xmlns="http://www.w3.org/1999/xhtml">
+	<p>The Asterisk project reports:</p>
+	<blockquote cite="http://www.asterisk.org/downloads/security-advisories">
+	  <p>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.</p>
+	  <p>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.</p>
+	  <p>If you do not use a proxy for authentication, then
+	  this issue does not affect you.</p>
+	  <p>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.</p>
+	  <p>If you use chan_pjsip instead of chan_sip, then this
+	  issue does not affect you.</p>
+	</blockquote>
+      </body>
+    </description>
+    <references>
+      <url>http://downloads.digium.com/pub/security/ASTERISK-2016-009.html</url>
+    </references>
+    <dates>
+      <discovery>2016-11-28</discovery>
+      <entry>2016-12-09</entry>
+    </dates>
+  </vuln>
+
+  <vuln vid="9e6640fe-be3a-11e6-b04f-001999f8d30b">
+    <topic>asterisk -- Crash on SDP offer or answer from endpoint using Opus</topic>
+    <affects>
+      <package>
+	<name>asterisk13</name>
+	<range><ge>13.12.0</ge><lt>13.13.1</lt></range>
+      </package>
+    </affects>
+    <description>
+      <body xmlns="http://www.w3.org/1999/xhtml">
+	<p>The Asterisk project reports:</p>
+	<blockquote cite="http://www.asterisk.org/downloads/security-advisories">
+	  <p>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.</p>
+	</blockquote>
+      </body>
+    </description>
+    <references>
+      <url>http://downloads.asterisk.org/pub/security/AST-2016-008.html</url>
+    </references>
+    <dates>
+      <discovery>2016-11-11</discovery>
+      <entry>2016-12-09</entry>
+    </dates>
+  </vuln>
+
   <vuln vid="eab68cff-bc0c-11e6-b2ca-001b3856973b">
     <topic>cryptopp -- multiple vulnerabilities</topic>
     <affects>
