[asterisk-bugs] [JIRA] (ASTERISK-24301) Security: Out of call MESSAGE requests processed via Message channel driver can crash Asterisk
Matt Jordan (JIRA)
noreply at issues.asterisk.org
Fri Sep 19 15:54:42 CDT 2014
[ https://issues.asterisk.org/jira/browse/ASTERISK-24301?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Matt Jordan updated ASTERISK-24301:
-----------------------------------
Target Release Version/s: 11.13.0
> Security: Out of call MESSAGE requests processed via Message channel driver can crash Asterisk
> ----------------------------------------------------------------------------------------------
>
> Key: ASTERISK-24301
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-24301
> Project: Asterisk
> Issue Type: Bug
> Components: Channels/chan_sip/Messaging, Resources/res_fax
> Affects Versions: 11.12.0, 12.5.0, 13.0.0-beta1
> Reporter: Matt Jordan
> Labels: Security
> Target Release: 11.12.1, 11.13.0, 12.5.1
>
> Attachments: ASTERISK-24301-fax.diff, ASTERISK-24301-formats13.diff
>
>
> *NOTE*: This is being treated as a security vulnerability for the following reasons:
> # It affects FreePBX fairly readily, which represents a very large percentage of Asterisk deployments
> # It's very easy to construct a dialplan that gets hit by this
> # It's good to fix crashes.
> From Philippe:
> The following scenario will crash Asterisk, confirmed on versions 11 and 12:
> Don't set the following {{sip.conf}} variables set:
> * {{accept_outofcall_messages}} (or set to no the default)
> * {{outofcall_message_context}} (not set in general or for a specific context)
> If you then receive an out of call SIP Message (SMS Message in this case) and the message is directed to {{ReceiveFAX()}} where, in my case we had spandsp installed, Asterisk will crash.
> Here is a trace of the CLI with SIP debug on:
> {code}
> <--- SIP read from UDP:192.159.66.3:5060 --->
> MESSAGE sip:2066514965 at 50.46.116.72:5060 SIP/2.0
> Via: SIP/2.0/UDP 192.159.66.3;rport;branch=z9hG4bK3yyvKHUN2mQFD
> Max-Forwards: 70
> From: <sip:14257365924 at 192.159.66.3>;tag=7UZZZ6jSe2H0a
> To: <sip:2066514965 at 50.46.116.72:5060>;did=2066514965
> Call-ID: 5f88785c-27e0-11e4-a024-9b0328f6df6f
> CSeq: 63335591 MESSAGE
> Contact: <sip:192.159.66.3>
> User-Agent: SIPStation 2.11.3
> Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
> Supported: timer, precondition, path, replaces
> Content-Type: text/plain
> Content-Length: 5
> X-FS-Sending-Message: ace24dea-1d2b-11e4-8238-9b0328f6df6f
> Again
> <------------->
> --- (14 headers 1 lines) ---
> Receiving message!
> Looking for 2066514965 in from-sip-external (domain 50.46.116.72)
> <--- Transmitting (NAT) to 192.159.66.3:5060 --->
> SIP/2.0 202 Accepted
> Via: SIP/2.0/UDP 192.159.66.3;branch=z9hG4bK3yyvKHUN2mQFD;received=192.159.66.3;rport=5060
> From: <sip:14257365924 at 192.159.66.3>;tag=7UZZZ6jSe2H0a
> To: <sip:2066514965 at 50.46.116.72:5060>;did=2066514965;tag=as14ddad00
> Call-ID: 5f88785c-27e0-11e4-a024-9b0328f6df6f
> CSeq: 63335591 MESSAGE
> Server: FPBX-2.11.0(11.3.0)
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
> Supported: replaces, timer
> Content-Length: 0
> <------------>
> Scheduling destruction of SIP dialog '5f88785c-27e0-11e4-a024-9b0328f6df6f' in 32000 ms (Method: MESSAGE)
> -- Executing [2066514965 at from-sip-external:1] NoOp("Message/ast_msg_queue", "Received incoming SIP connection from unknown peer to 2066514965") in new stack
> -- Executing [2066514965 at from-sip-external:2] Set("Message/ast_msg_queue", "DID=2066514965") in new stack
> -- Executing [2066514965 at from-sip-external:3] Goto("Message/ast_msg_queue", "s,1") in new stack
> -- Goto (from-sip-external,s,1)
> -- Executing [s at from-sip-external:1] GotoIf("Message/ast_msg_queue", "1?checklang:noanonymous") in new stack
> -- Goto (from-sip-external,s,2)
> -- Executing [s at from-sip-external:2] GotoIf("Message/ast_msg_queue", "0?setlanguage:from-trunk,2066514965,1") in new stack
> -- Goto (from-trunk,2066514965,1)
> -- Executing [2066514965 at from-trunk:1] Set("Message/ast_msg_queue", "FAX_FOR=Philippe Office (222)") in new stack
> -- Executing [2066514965 at from-trunk:2] NoOp("Message/ast_msg_queue", "Receiving Fax for: Philippe Office (222), From: "" <>") in new stack
> -- Executing [2066514965 at from-trunk:3] Set("Message/ast_msg_queue", "FAX_RX_EMAIL=philippe at espressofountain.com") in new stack
> -- Executing [2066514965 at from-trunk:4] StopPlayTones("Message/ast_msg_queue", "") in new stack
> -- Executing [2066514965 at from-trunk:5] ReceiveFAX("Message/ast_msg_queue", "/var/spool/asterisk/fax/1408464436.0.tif,f") in new stack
> localhost*CLI>
> Disconnected from Asterisk server
> Asterisk cleanly ending (0).
> Executing last minute cleanups
> {code}
> Here are the modules:
> {code}
> localhost*CLI> module show like fax
> Module Description Use Count
> res_fax.so Generic FAX Applications 1
> res_fax_spandsp.so Spandsp G.711 and T.38 FAX Technologies 0
> 2 modules loaded
> {code}
> Here is the actual snip it of dialplan I used to regenerate this:
> {code}
> exten => 2066514965,1,Set(FAX_FOR=Philippe Office (222))
> exten => 2066514965,n,Noop(Receiving Fax for: ${FAX_FOR}, From: ${CALLERID(all)})
> exten => 2066514965,n,Set(FAX_RX_EMAIL=philippe at espressofountain.com)
> exten => 2066514965,n(receivefax),StopPlaytones
> exten => 2066514965,n,ReceiveFAX(${ASTSPOOLDIR}/fax/${UNIQUEID}.tif,f)
> exten => 2066514965,n,ExecIf($["${FAXSTATUS:0:6}"="FAILED" && "${FAXERROR}"!="INIT_ERROR"]?Set(FAXSTATUS="FAILED: error: ${FAXERROR} statusstr: ${FAXOPT(statusstr)}"))
> exten => 2066514965,n,Hangup
> {code}
> In FreePBX it can be easily reproduced by sending an inbound DID directly to a 'FAX Recipient' destination which is setup in the Extension Page first.
> From an earlier test of this (I think verbosity was set higher or I had better logging), the following ERROR messages are included:
> {code}
> [2014-08-19 08:43:37] VERBOSE[24146][C-00000001] res_fax.c: -- Channel 'Message/ast_msg_queue' receiving FAX '/var/spool/asterisk/fax/1408463017.1.tif'
> [2014-08-19 08:43:37] WARNING[24146][C-00000001] channel.c: Unable to find a codec translation path from (nothing) to (slin)
> [2014-08-19 08:43:37] ERROR[24146][C-00000001] res_fax.c: channel 'Message/ast_msg_queue' failed to set write format to signed linear'.
> {code}
> I believe this should be pretty easy to reproduce. The severity of this is not super high since you have to be pointing the message at a DID that routes to ReceiveFAX, but if anonymous SIP is allowed on an Asterisk installation and there is a route to ReceiveFAX then the system could be subject to a DoS attack that will crash Asterisk. And of course, users could easily configure a box with bad routing to have the same result...
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list