{ "containers": { "cna": { "affected": [ { "product": "n/a", "vendor": "n/a", "versions": [ { "status": "affected", "version": "n/a" } ] } ], "datePublic": "2016-12-12T00:00:00.000Z", "descriptions": [ { "lang": "en", "value": "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." } ], "problemTypes": [ { "descriptions": [ { "description": "n/a", "lang": "en", "type": "text" } ] } ], "providerMetadata": { "dateUpdated": "2017-07-26T09:57:01.000Z", "orgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca", "shortName": "mitre" }, "references": [ { "tags": [ "x_refsource_CONFIRM" ], "url": "http://downloads.asterisk.org/pub/security/AST-2016-009.html" }, { "name": "94789", "tags": [ "vdb-entry", "x_refsource_BID" ], "url": "http://www.securityfocus.com/bid/94789" }, { "name": "1037408", "tags": [ "vdb-entry", "x_refsource_SECTRACK" ], "url": "http://www.securitytracker.com/id/1037408" } ], "x_legacyV4Record": { "CVE_data_meta": { "ASSIGNER": "cve@mitre.org", "ID": "CVE-2016-9938", "STATE": "PUBLIC" }, "affects": { "vendor": { "vendor_data": [ { "product": { "product_data": [ { "product_name": "n/a", "version": { "version_data": [ { "version_value": "n/a" } ] } } ] }, "vendor_name": "n/a" } ] } }, "data_format": "MITRE", "data_type": "CVE", "data_version": "4.0", "description": { "description_data": [ { "lang": "eng", "value": "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." } ] }, "problemtype": { "problemtype_data": [ { "description": [ { "lang": "eng", "value": "n/a" } ] } ] }, "references": { "reference_data": [ { "name": "http://downloads.asterisk.org/pub/security/AST-2016-009.html", "refsource": "CONFIRM", "url": "http://downloads.asterisk.org/pub/security/AST-2016-009.html" }, { "name": "94789", "refsource": "BID", "url": "http://www.securityfocus.com/bid/94789" }, { "name": "1037408", "refsource": "SECTRACK", "url": "http://www.securitytracker.com/id/1037408" } ] } } }, "adp": [ { "providerMetadata": { "orgId": "af854a3a-2127-422b-91ae-364da2661108", "shortName": "CVE", "dateUpdated": "2024-08-06T03:07:31.471Z" }, "title": "CVE Program Container", "references": [ { "tags": [ "x_refsource_CONFIRM", "x_transferred" ], "url": "http://downloads.asterisk.org/pub/security/AST-2016-009.html" }, { "name": "94789", "tags": [ "vdb-entry", "x_refsource_BID", "x_transferred" ], "url": "http://www.securityfocus.com/bid/94789" }, { "name": "1037408", "tags": [ "vdb-entry", "x_refsource_SECTRACK", "x_transferred" ], "url": "http://www.securitytracker.com/id/1037408" } ] } ] }, "cveMetadata": { "assignerOrgId": "8254265b-2729-46b6-b9e3-3dfca2d5bfca", "assignerShortName": "mitre", "cveId": "CVE-2016-9938", "datePublished": "2016-12-12T21:00:00.000Z", "dateReserved": "2016-12-12T00:00:00.000Z", "dateUpdated": "2024-08-06T03:07:31.471Z", "state": "PUBLISHED" }, "dataType": "CVE_RECORD", "dataVersion": "5.1" }