Search Results (Refine Search)
- Results Type: Overview
- Keyword (text search): cpe:2.3:a:digium:asterisk:13.3.1:*:*:*:*:*:*:*
- CPE Name Search: true
Vuln ID | Summary | CVSS Severity |
---|---|---|
CVE-2017-16671 |
A Buffer Overflow issue was discovered in Asterisk Open Source 13 before 13.18.1, 14 before 14.7.1, and 15 before 15.1.1 and Certified Asterisk 13.13 before 13.13-cert7. No size checking is done when setting the user field for Party B on a CDR. Thus, it is possible for someone to use an arbitrarily large string and write past the end of the user field storage buffer. NOTE: this is different from CVE-2017-7617, which was only about the Party A buffer. Published: November 08, 2017; 7:29:00 PM -0500 |
V4.0:(not available) V3.0: 8.8 HIGH V2.0: 6.5 MEDIUM |
CVE-2016-7551 |
chain_sip in Asterisk Open Source 11.x before 11.23.1 and 13.x 13.11.1 and Certified Asterisk 11.6 before 11.6-cert15 and 13.8 before 13.8-cert3 allows remote attackers to cause a denial of service (port exhaustion). Published: April 17, 2017; 12:59:00 PM -0400 |
V4.0:(not available) V3.0: 7.5 HIGH V2.0: 5.0 MEDIUM |
CVE-2016-9938 |
An issue was discovered in Asterisk Open Source 11.x before 11.25.1, 13.x before 13.13.1, and 14.x before 14.2.1 and Certified Asterisk 11.x before 11.6-cert16 and 13.x before 13.8-cert4. 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. Published: December 12, 2016; 4:59:01 PM -0500 |
V4.0:(not available) V3.0: 5.3 MEDIUM V2.0: 5.0 MEDIUM |
CVE-2015-3008 |
Asterisk Open Source 1.8 before 1.8.32.3, 11.x before 11.17.1, 12.x before 12.8.2, and 13.x before 13.3.2 and Certified Asterisk 1.8.28 before 1.8.28-cert5, 11.6 before 11.6-cert11, and 13.1 before 13.1-cert2, when registering a SIP TLS device, does not properly handle a null byte in a domain name in the subject's Common Name (CN) field of an X.509 certificate, which allows man-in-the-middle attackers to spoof arbitrary SSL servers via a crafted certificate issued by a legitimate Certification Authority. Published: April 10, 2015; 11:00:10 AM -0400 |
V4.0:(not available) V3.x:(not available) V2.0: 4.3 MEDIUM |