[asterisk-dev] AMI 'originate' permission is broken [was: Re: AST-2012-012: Asterisk Manager User Unauthorized Shell Access]

[Matthew Jordan]

----- Original Message -----
> From: "Tzafrir Cohen" <tzafrir.cohen at xorcom.com>
> To: asterisk-dev at lists.digium.com
> Sent: Tuesday, September 4, 2012 4:14:40 AM
> Subject: Re: [asterisk-dev] AMI 'originate' permission is broken	[was:	Re:	AST-2012-012: Asterisk Manager User
> Unauthorized	Shell Access]
> 
> On Mon, Sep 03, 2012 at 05:30:23PM -0500, Matthew  Jordan wrote:
> > 
> > ----- Original Message -----
> > > From: "Tzafrir Cohen" <tzafrir.cohen at xorcom.com>
> > > To: asterisk-dev at lists.digium.com
> > > Sent: Monday, September 3, 2012 8:33:34 AM
> > > Subject: Re: [asterisk-dev] AMI 'originate' permission is broken
> > > [was:	Re:	AST-2012-012: Asterisk Manager User
> > > Unauthorized Shell Access]
> > > 
> > > On Sat, Sep 01, 2012 at 07:33:29PM -0500, Matthew  Jordan wrote:
> > > 
> > > 
> > > If Application is given, the 'originate' permission will not be
> > > used.
> > > So
> > > we don't need to worry about this one.
> > 
> > That is not the current behavior.  You do not need a permission
> > other than the
> > originate permission to execute an application.
> 
> Right. But my original point in this thread was that if one can
> execute
> an application, one can effectively create a dialplan, which is
> inherently insecure.

Agreed.  Except that I don't see a way to modify the current behavior without
breaking applications that depend on the ability to specify a dialplan
application.
 
> So what I'd like to know is what's the use case for an "unpriviliged"
> Originate with Application/Data?
> 

Creating channels that drop into a conference and Playback a single sound file
comes to mind.  I'm sure other folks can come up with other use cases.

In all cases, you could construct a dialplan that would provide the same
functionality; the application specifier was clearly meant as a convenience
for when you only needed a single application to execute.  The updated README
was the result of the realization that we've released three security releases
to deal with this problem, all of which have used the 'blacklist' solution to
resolve the problem.  The fact that Asterisk is modular and we can't predict
what all applications may be loaded into Asterisk means that this solution
is inherently limited.  Coupled with the fact that dialplan execution can also
be compromised (for sufficiently poorly written dialplans) means that we're
at a point where we don't want to continue to release patches for this problem
that don't conclusively solve the problem.

Of course, if someone would like to come up with a comprehensive solution that
does not break existing third party application, I'd be thrilled to support it.

--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org