ubuntu-cve-2016-9938
Vulnerability from osv_ubuntu
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": [
{
"ecosystem_specific": {
"binaries": [
{
"binary_name": "asterisk",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-config",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-dahdi",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-mobile",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-modules",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-mp3",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-mysql",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-ooh323",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-voicemail",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-voicemail-imapstorage",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-voicemail-odbcstorage",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
},
{
"binary_name": "asterisk-vpb",
"binary_version": "1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
}
]
},
"package": {
"ecosystem": "Ubuntu:Pro:16.04:LTS",
"name": "asterisk",
"purl": "pkg:deb/ubuntu/asterisk@1:13.1.0~dfsg-1.1ubuntu4.1+esm1?arch=source\u0026distro=esm-apps/xenial"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
],
"versions": [
"1:13.1.0~dfsg-1.1ubuntu3",
"1:13.1.0~dfsg-1.1ubuntu4",
"1:13.1.0~dfsg-1.1ubuntu4.1",
"1:13.1.0~dfsg-1.1ubuntu4.1+esm1"
]
}
],
"aliases": [],
"details": "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.",
"id": "UBUNTU-CVE-2016-9938",
"modified": "2026-04-22T07:38:05Z",
"published": "2016-12-12T21:59:00Z",
"references": [
{
"type": "REPORT",
"url": "https://ubuntu.com/security/CVE-2016-9938"
},
{
"type": "REPORT",
"url": "http://downloads.asterisk.org/pub/security/AST-2016-009.html"
},
{
"type": "REPORT",
"url": "https://issues.asterisk.org/jira/browse/ASTERISK-26433"
},
{
"type": "REPORT",
"url": "https://www.cve.org/CVERecord?id=CVE-2016-9938"
}
],
"related": [],
"schema_version": "1.7.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
},
{
"score": "low",
"type": "Ubuntu"
}
],
"upstream": [
"CVE-2016-9938"
]
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.