[asterisk-users] How to allow AMI access to Originate yet deny Application: System

[Alex Villací­s Lasso]

While doing a security audit on a system I maintain, I stumbled upon an unvalidated use of a variable to compose an Originate request to the local Asterisk instance via AMI. Taking as an example an earlier exploit for FreePBX, I realized that this, 
combined with Application: System as an injected value, could allow arbitrary code execution. I am in the process of fixing all instances of this bug in our system. However, there are third parties that plug into our system, and that reconfigure the 
manager.conf file to allow remote access to AMI logins that allow Originate (by default, the manager.conf remains configured to deny login to any system except localhost). I want to have a guideline on how to proceed in order to make these applications 
work, without allowing malicious users to compromise the system. I know that one way to proceed is to deny remote access to AMI, and build an application-specific proxy that will perform the Originate on behalf of the remote requester, after filtering the 
values. However, I want to know if there is a simpler way to remove the danger of code execution while allowing applications to use AMI to place calls.

The intended scenario is that a remote desktop application (for Windows) is configured with the AMI credentials, and connects over the LAN to Asterisk in order to place calls and otherwise monitor the system. The attack I want to protect against is that of 
a malicious user that collects the credentials from the desktop application and proceeds to use the Application: System trick. I know of the SSL support for AMI, but it will not protect against a malicious end user.