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

[Jonathan Rose]

Tzafrir Cohen wrote on Tuesday, September 4, 2012 4:14:40 AM
> 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.
> 
> So what I'd like to know is what's the use case for an "unpriviliged"
> Originate with Application/Data?

Well, one use-case I can immediately think of would be a custom
agent login done through a of GUI. You know, do things like let
a user specify what agent he/she is going to log into from a web
interface of some kind and then use the data put into those fields
as the app data for originate.

A lot of these examples would hinge on GUI stuff really.

I'm going to go ahead and throw out a couple ideas to address this
problem and you all can tell me how inherently flawed they are or
however you feel about them really...

Split the Originate permission into two separate permissions. One
would allow you to originate only using existing extensions from the
dial plan and only to contexts currently allowed to the device in
question while the other would function like originate currently
functions allowing you to originate with application/appData as well.

Alternatively, while passing security information down to specific
apps is overkill, we could give applications a callback to evaluate
whether a given set of appData could present a problem with permission
escalation. This callback could return a bitfield indicating any and
all permissions that could be raised by the given appData string. Simple
implementations of the callback might just return all of the permission
escalations that could be caused by any set of appData without actually
evaluating the incoming appData and more complex approaches would actually
check for things like what arguments are specified by the appData.