Allele Security Alert
ASA-2019-00422, CVE-2019-13161, AST-2019-003
Remote crash in chan_sip channel driver
Asterisk Open Source
Certified Asterisk all releases from version 13.21
Asterisk Open Source all releases from version 13.x
Asterisk Open Source all releases from version 15.x
Asterisk Open Source all releases from version 16.x
Certified Asterisk version 13.21-cert4
Asterisk Open Source version 13.27.1
Asterisk Open Source version 15.7.3
Asterisk Open Source version 16.4.1
Proof of concept
When T.38 faxing is done in Asterisk a T.38 reinvite may be sent to an endpoint to switch it to T.38. If the endpoint responds with an improperly formatted SDP answer including both a T.38 UDPTL stream and an audio or video stream containing only codecs not allowed on the SIP peer or user a crash will occur. The code incorrectly assumes that there will be at least one common codec when T.38 is also in the SDP answer.
This requires Asterisk to initiate a T.38 reinvite which is only done when executing the ReceiveFax dialplan application or performing T.38 passthrough where a remote endpoint has requested T.38.
Asterisk-13 based gateways experienced occasional segfaults, and inspecting with GDB their coredumps, the author concluded they are caused by a very specific case in process_sdp() of chan_sip.c:
- Asterisk has been configured with preferred_codec_only for the relevant peer, and e list, possibly restrictive, of codecs
- the SIP peer starts a valid session through Asterisk (chan_sip) as a B2BUA
- Asterisk issue a T.38 reINVITE (for example with ReceiveFAX application, even if it was not our case)
- the SIP UA (UAS in this case) responds with a “broken” SDP with two m-lines, one for an audio codec not included in the SIP peer allowed list, and another with image/t38
Such an SDP is broken because a SIP UA is not allowed to responds with multiple m-lines whenever it received just one m-line.
Broken SDP can cause a segfault in a T.38 reINVITE
If there is any error in this alert or you wish a comprehensive analysis, let us know.
Last modified: September 23, 2019