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

[Matthew Jordan]

----- Original Message -----
> From: "Olle E. Johansson" <oej at edvina.net>
> To: "Asterisk Developers Mailing List" <asterisk-dev at lists.digium.com>
> Cc: "Olle E. Johansson" <oej at edvina.net>
> Sent: Saturday, September 1, 2012 9:27:29 AM
> Subject: Re: [asterisk-dev] AMI 'originate' permission is broken [was: Re:	AST-2012-012: Asterisk Manager User
> Unauthorized Shell Access]
> 
> 
> 1 sep 2012 kl. 12:30 skrev Tzafrir Cohen <tzafrir.cohen at xorcom.com>:
> 

<snip>

> > I believe this means that the 'originate' permission is broken: it
> > can't
> > guarantee anything. The thing is that as long as a user can create
> > an
> > Asterisk dialplan, there's really no good way of properly
> > containing
> > that user.

I agree with that sentiment.  I might go one further and state that the
concept of limiting permission based on certain 'classes' is broken.  The
classes may limit the AMI commands that a user can execute; they don't
have any effect on the dialplan applications that are executed on the channel
once the channel is created.  This is why you essentially have to consider
the 'originate' class as being as high a permission as possible.

> > So maybe this means that the 'originate' permission should not
> > grant
> > permission to the 'Application' form of originating a call?
> > 'originate'
> > should be a simple method of creating a call to an existing
> > context.

There are still ways around this, unless you want to parse and validate
every application/data fields passed in with an Originate action.  Even then,
the fact that you can create a Local channel and send one half of it into
any arbitrary context means you can exploit poorly written dialplans.

> > Q: But it breaks existing systems!
> > 
> > A: The fact that 'originate' does not protect you from full access
> >   breaks systems. If you don't want the limited form, just give the
> >   user the 'system' permission and be done with it. Heck, chances
> >   are
> >   you already do :-( .
> > 
> > Alternatively: maybe nobody uses this permission and it should be
> > deprecated / removed?

I would be fine with deprecating the originate class permission.  Its pretty
much what the README implies: originate is the same as system.

Outside of warning people, the most permanent solution we could come up with
was to have every dialplan application, ExternalIVR command, and AGI command
register itself with a class permission.  The channel created from an
Originate action would have its class permissions stored on it, and every
application/function/ExternalIVR/AGI executed by the channel would be checked
against the allowed class permissions on the channel.

This may work; however, you would be almost certain to restrict (and therefore
break) currently valid dialplans and configurations. You would be almost certain
to break a large majority of third party applications.  Rather than wreak havoc
on a large number of systems, we opted for the description in the README and
some strenuous suggestions to make sure your users are authenticated and you
don't run Asterisk as root.

This feels like one of those times where the solution would be far worse than
the original problem.

That being said, I'd certainly love to see a more comprehensive solution for
Asterisk 12.  At least then any solution to the problem is in a major release,
and won't catch users by surprise.

> Just to limit originate a bit more I have a branch with a context=
> definition
> for manager originate and redirect, so you can limit the manager
> account
> from reaching all of your dialplan.
> 
> That's a small step in the right direction. It's been on subversion
> for a long
> time. Don't remember if it's been on reviewboard, but this might be a
> good
> time to upload it.

That would certainly be a step in the right direction, and would help to limit
some more common ways of exploiting this problem.  You would have to also scan
the application data field to catch malicious dialplan redirections.

I have a feeling that this could be exploited even with such a restriction.
Without a comprehensive class permission system, there is probably a way that
an authenticated user could do something that the dialplan writer did not
intend, if they have the ability to create channels.


--
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