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.
Upstream:released (1:13.13.1~dfsg-1)
Ubuntu 12.04 ESM (Precise Pangolin):DNE (precise was needed)
Ubuntu 14.04 ESM (Trusty Tahr):DNE (trusty was needed)
Ubuntu 16.04 LTS (Xenial Xerus):needed
Ubuntu 18.04 LTS (Bionic Beaver):not-affected (1:13.13.1~dfsg-1)
Ubuntu 19.10 (Eoan Ermine):not-affected (1:13.13.1~dfsg-1)
Ubuntu 20.04 (Focal Fossa):not-affected (1:13.13.1~dfsg-1)
More Information

Updated: 2020-04-24 03:34:45 UTC (commit d3f8a6ed481830fb100109a132bef581fc4176fe)