| パッケージ | 影響を受けるバージョン | 修正済みバージョン |
|---|---|---|
| asterisk | = 11.0.0= 11.0.1= 11.0.2= 11.1.0= 11.1.1= 11.1.2= 11.10.0= 11.10.1= 11.10.2= 11.11.0= 11.12.0= 11.12.1= 11.13.0= 11.13.1= 11.14.0= 11.14.1= 11.14.2= 11.15.0= 11.15.1= 11.16.0= 11.17.0= 11.17.1= 11.18.0= 11.19.0= 11.2.0= 11.2.1= 11.2.2= 11.20.0= 11.21.0= 11.21.1= 11.21.2= 11.22.0= 11.23.0= 11.23.1= 11.24.0= 11.24.1= 11.25.0= 11.3.0= 11.4.0= 11.5.0= 11.5.1= 11.6.0= 11.6.1= 11.7.0= 11.8.0= 11.8.1= 11.9.0= 13.0.0= 13.0.1= 13.0.2= 13.1.0= 13.1.1= 13.10.0= 13.11.0= 13.11.1= 13.11.2= 13.12.0= 13.12.1= 13.12.2= 13.13.0= 13.2.0= 13.2.1= 13.3.0= 13.3.1= 13.3.2= 13.4.0= 13.5.0= 13.6.0= 13.7.0= 13.7.1= 13.7.2= 13.8.0= 13.8.1= 13.8.2= 13.9.0= 13.9.1= 14.0.0= 14.0.1= 14.0.2= 14.1.0= 14.1.1= 14.1.2= 14.2.0 | |
| certified asterisk | = 11.0.0= 11.1.0= 11.2.0= 11.3.0= 11.4.0= 11.5.0= 11.6= 11.6.0 |
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.
これらの製品をお使いですか?サイトをスキャンして、脆弱なバージョンが公開されていないか確認しましょう。
無料でサイトをスキャン