Date: Fri, 9 Dec 2016 19:44:12 +0000 (UTC) From: Guido Falsi <madpilot@FreeBSD.org> To: ports-committers@freebsd.org, svn-ports-all@freebsd.org, svn-ports-head@freebsd.org Subject: svn commit: r428237 - head/security/vuxml Message-ID: <201612091944.uB9JiC2S032191@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201612091944.uB9JiC2S032191>