SignalWire advisory

sofia_presence_handle_sip_i_message() splits the To user of an inbound SIP MESSAGE on + and treats the left half as a chat proto name, dispatching the message to whichever registered chat interface matches. mod_dptools registers an api chat interface that hands its address to switch_api_execute() . A peer that can deliver a MESSAGE to a profile therefore selects which FreeSWITCH API command the server runs. Nothing restricts the selector, and message-delivery protos are not distinguished from command-execution protos.

Command execution with the privileges of the FreeSWITCH process: arbitrary OS commands, disclosure of configuration and credentials, and full call control. Where mod_lua is loaded, as stock configuration does, inline Lua with the full standard library is reachable as a second sink. Exploitation of this path has been observed in the wild.

Affected configurations

Any SIP profile that accepts inbound MESSAGE, which is the default posture: chat handling is on unless a profile sets enable-chat=false , and stock conf/vanilla leaves it on for both the internal and external profiles. No non-default setting is required. The inbound ACL does not cover MESSAGE, so tightening it does not take a profile out of scope.

Getting a single SIP MESSAGE accepted by a profile. Where MESSAGE authentication is enforced, any one account on that profile is enough: an extension, a handset, or a trunk peer, holding no permission beyond the ability to register. Installations that still carry conf/vanilla/directory/default/default.xml need no account of their own: that file defines with no password and no a1-hash , and a directory user with neither authenticates successfully unless allow-empty-password is set to false for it.

enable-chat=false on every profile that does not need inbound SIP chat. This stops the message before the proto selector is parsed, and disables all inbound MESSAGE chat delivery on that profile.

auth-messages is not sufficient on its own. MESSAGE authentication is enabled by default from version 1.10.7 onward. Combined with removing every directory user that has no password or a1-hash - stock conf/vanilla ships two, default and the Skinny example - it reduces this to authenticated command execution, but does not close the path.

disable_system_api_commands=true removes the system API but not the route, which still reaches every other registered API, including module loading and call origination. Worth setting, but it does not close this path.

A new per-profile enable-chat-api-proto parameter controls whether an inbound MESSAGE may select the api chat proto, and is off unless explicitly set, so the route is closed on every profile by default. A MESSAGE selecting the proto where it is not enabled is answered 403 and logged with the source and the requested command. The comparison is case-insensitive, matching the chat interface registry. Messages carrying no proto selector, or naming another chat proto, route unchanged. The parameter ships commented out in the vanilla profiles and the mod_sofia configuration sample.

Örn Arnarson and Gunnlaugur.