{"id":"CVE-2016-9938","state":"PUBLISHED","title":"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","description":"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.","publishedAt":"2016-12-12T21:00:00.000Z","updatedAt":"2024-08-06T03:07:31.471Z","severity":null,"assigner":"mitre","products":["n/a n/a"],"affected":[{"vendor":"n/a","product":"n/a","versions":[{"version":"n/a","status":"affected"}]}],"references":["http://downloads.asterisk.org/pub/security/AST-2016-009.html","http://www.securityfocus.com/bid/94789","http://www.securitytracker.com/id/1037408"],"weaknesses":[],"ingestedAt":"2026-10-29T19:42:58.401Z","source":{"repository":"CVEProject/cvelistV5","path":"cves/2016/9xxx/CVE-2016-9938.json","commit":"556c9d3a8cd17e218bb8e452ba7cd619a384ff47"},"raw":{"dataType":"CVE_RECORD","dataVersion":"5.1","cveMetadata":{"cveId":"CVE-2016-9938","state":"PUBLISHED","datePublished":"2016-12-12T21:00:00.000Z","dateUpdated":"2024-08-06T03:07:31.471Z","assignerShortName":"mitre","assignerOrgId":"8254265b-2729-46b6-b9e3-3dfca2d5bfca","dateReserved":"2016-12-12T00:00:00.000Z"},"containers":{"cna":{"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."}],"affected":[{"vendor":"n/a","product":"n/a","versions":[{"version":"n/a","status":"affected"}]}],"references":[{"url":"http://downloads.asterisk.org/pub/security/AST-2016-009.html","tags":["x_refsource_CONFIRM"]},{"url":"http://www.securityfocus.com/bid/94789","name":"94789","tags":["vdb-entry","x_refsource_BID"]},{"url":"http://www.securitytracker.com/id/1037408","name":"1037408","tags":["vdb-entry","x_refsource_SECTRACK"]}],"problemTypes":[{"descriptions":[{"description":"n/a","lang":"en","type":"text"}]}],"providerMetadata":{"shortName":"mitre","dateUpdated":"2017-07-26T09:57:01.000Z","orgId":"8254265b-2729-46b6-b9e3-3dfca2d5bfca"},"datePublic":"2016-12-12T00:00:00.000Z","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":[{"title":"CVE Program Container","references":[{"url":"http://downloads.asterisk.org/pub/security/AST-2016-009.html","tags":["x_refsource_CONFIRM","x_transferred"]},{"url":"http://www.securityfocus.com/bid/94789","name":"94789","tags":["vdb-entry","x_refsource_BID","x_transferred"]},{"url":"http://www.securitytracker.com/id/1037408","name":"1037408","tags":["vdb-entry","x_refsource_SECTRACK","x_transferred"]}],"providerMetadata":{"shortName":"CVE","orgId":"af854a3a-2127-422b-91ae-364da2661108","dateUpdated":"2024-08-06T03:07:31.471Z"}}]}}}