Search Results (Refine Search)
- Results Type: Overview
- Keyword (text search): cpe:2.3:a:digium:certified_asterisk:11.6:cert12:*:*:lts:*:*:*
Vuln ID | Summary | CVSS Severity |
---|---|---|
CVE-2019-13161 |
An issue was discovered in Asterisk Open Source through 13.27.0, 14.x and 15.x through 15.7.2, and 16.x through 16.4.0, and Certified Asterisk through 13.21-cert3. A pointer dereference in chan_sip while handling SDP negotiation allows an attacker to crash Asterisk when handling an SDP answer to an outgoing T.38 re-invite. To exploit this vulnerability an attacker must cause the chan_sip module to send a T.38 re-invite request to them. Upon receipt, the attacker must send an SDP answer containing both a T.38 UDPTL stream and another media stream containing only a codec (which is not permitted according to the chan_sip configuration). Published: July 12, 2019; 4:15:11 PM -0400 |
V3.1: 5.3 MEDIUM V2.0: 3.5 LOW |
CVE-2018-17281 |
There is a stack consumption vulnerability in the res_http_websocket.so module of Asterisk through 13.23.0, 14.7.x through 14.7.7, and 15.x through 15.6.0 and Certified Asterisk through 13.21-cert2. It allows an attacker to crash Asterisk via a specially crafted HTTP request to upgrade the connection to a websocket. Published: September 24, 2018; 6:29:01 PM -0400 |
V3.0: 7.5 HIGH V2.0: 5.0 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 |
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 |
V3.0: 5.3 MEDIUM V2.0: 5.0 MEDIUM |