svn commit: r441277 - head/security/vuxml

Guido Falsi madpilot at FreeBSD.org
Fri May 19 22:59:57 UTC 2017


Author: madpilot
Date: Fri May 19 22:59:56 2017
New Revision: 441277
URL: https://svnweb.freebsd.org/changeset/ports/441277

Log:
  Document net/asterisk13 and net/pjsip vulnerabilities.

Modified:
  head/security/vuxml/vuln.xml

Modified: head/security/vuxml/vuln.xml
==============================================================================
--- head/security/vuxml/vuln.xml	Fri May 19 22:30:16 2017	(r441276)
+++ head/security/vuxml/vuln.xml	Fri May 19 22:59:56 2017	(r441277)
@@ -58,6 +58,90 @@ Notes:
   * Do not forget port variants (linux-f10-libxml2, libxml2, etc.)
 -->
 <vuxml xmlns="http://www.vuxml.org/apps/vuxml-1">
+  <vuln vid="fab87bff-3ce5-11e7-bf9d-001999f8d30b">
+    <topic>asterisk -- Memory exhaustion on short SCCP packets</topic>
+    <affects>
+      <package>
+	<name>asterisk13</name>
+	<range><lt>13.15.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>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.</p>
+	</blockquote>
+      </body>
+    </description>
+    <references>
+      <url>http://downloads.asterisk.org/pub/security/AST-2017-004.html</url>
+    </references>
+    <dates>
+      <discovery>2017-04-13</discovery>
+      <entry>2017-05-19</entry>
+    </dates>
+  </vuln>
+
+  <vuln vid="0537afa3-3ce0-11e7-bf9d-001999f8d30b">
+    <topic>asterisk -- Buffer Overrun in PJSIP transaction layer</topic>
+    <affects>
+      <package>
+	<name>asterisk13</name>
+	<range><lt>13.15.1</lt></range>
+      </package>
+      <package>
+	<name>pjsip</name>
+	<range><lt>2.6_1</lt></range>
+      </package>
+      <package>
+	<name>pjsip-extsrtp</name>
+	<range><lt>2.6_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>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.</p>
+	  <p>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.</p>
+	  <p>This issues 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.</p>
+	  <p>If you are running Asterisk with chan_sip, this issue
+	  does not affect you.</p>
+	</blockquote>
+      </body>
+    </description>
+    <references>
+      <url>http://downloads.asterisk.org/pub/security/AST-2017-002.html</url>
+      <url>http://downloads.asterisk.org/pub/security/AST-2017-003.html</url>
+    </references>
+    <dates>
+      <discovery>2017-04-12</discovery>
+      <entry>2017-05-19</entry>
+    </dates>
+  </vuln>
+
   <vuln vid="3c2549b3-3bed-11e7-a9f0-a4badb296695">
     <topic>Joomla3 -- SQL Injection</topic>
     <affects>


More information about the svn-ports-all mailing list