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

[Olle E. Johansson]

2 sep 2012 kl. 02:33 skrev "Matthew  Jordan" <mjordan at digium.com>:

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


Well, that's manager. You can run any dialplan function and any application at any
point in time. Manager is meant to control the pbx and by allowing users access
through manager, you open up for total control. We can limit in various ways,
but I don't believe it is ever going to be an end-user API that should be open for normal
and untrusted users.

/O
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2307 bytes
Desc: not available
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20120902/f53d40e7/attachment.bin>