asterisk users - May 2013 - How to allow AMI access to Originate yet deny Application: System

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.

El 15/05/13 10:10, Alex Villac??s Lasso escribi?:
> 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.
Is this question too basic, or just cannot be done other than with the proxy
approach?