The Asterisk project reports:
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 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.
With Rapid7 live dashboards, I have a clear view of all the assets on my network, which ones can be exploited, and what I need to do in order to reduce the risk in my environment in real-time. No other tool gives us that kind of value and insight.
– Scott Cheney, Manager of Information Security, Sierra View Medical Center