diff options
| author | Guido Falsi <madpilot@FreeBSD.org> | 2017-05-19 22:59:56 +0000 |
|---|---|---|
| committer | Guido Falsi <madpilot@FreeBSD.org> | 2017-05-19 22:59:56 +0000 |
| commit | d549dd6ac1ae76a853e101f6f96c7bd01825cec0 (patch) | |
| tree | 0e53af93bbcac3905da4531c790e71890febace6 /security/vuxml | |
| parent | 5fc4be1ab42c85576627d935b1956daae5c6b52e (diff) | |
| download | ports-d549dd6ac1ae76a853e101f6f96c7bd01825cec0.tar.gz ports-d549dd6ac1ae76a853e101f6f96c7bd01825cec0.zip | |
Document net/asterisk13 and net/pjsip vulnerabilities.
Notes
Notes:
svn path=/head/; revision=441277
Diffstat (limited to 'security/vuxml')
| -rw-r--r-- | security/vuxml/vuln.xml | 84 |
1 files changed, 84 insertions, 0 deletions
diff --git a/security/vuxml/vuln.xml b/security/vuxml/vuln.xml index d4a81af9778e..f993c54d84cf 100644 --- a/security/vuxml/vuln.xml +++ b/security/vuxml/vuln.xml @@ -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> |