The design of the dialplan functionality in Asterisk Open Source 1.2.x, 1.4.x, and 1.6.x; and Asterisk Business Edition B.x.x and C.x.x, when using the ${EXTEN} channel variable and wildcard pattern matches, allows context-dependent attackers to inject strings into the dialplan using metacharacters that are injected when the variable is expanded, as demonstrated using the Dial application to process a crafted SIP INVITE message that adds an unintended outgoing channel leg. NOTE: it could be argued that this is not a vulnerability in Asterisk, but a class of vulnerabilities that can occur in any program that uses this feature without the associated filtering functionality that is already available.

Stack-based buffer overflow in the function that parses commands in Asterisk 1.0.7, when the 'write = command' option is enabled, allows remote attackers to execute arbitrary code via a command that has two double quotes followed by a tab character.

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.