[asterisk-dev] Dialstring vulnerability and switch =

[Olle E. Johansson]

17 feb 2010 kl. 15.29 skrev Russell Bryant:

> On 02/17/2010 03:14 AM, Olle E. Johansson wrote:
>> In our sample extensions.conf, there are a few switches included in the default context. How are these affected?
>> I think it should be mentioned as an issue in the README too...
> 
> Let's go over the types of switches and how they might be affected ...
> 
> 1) IAX2 Switch
> 
> This effectively lets you do a remote dialplan lookup.  If it matches, 
> it will send the call over IAX2.  The remote dialplan will need to be 
> secured just like the local dialplan.
> 
> 2) Loopback switch
> 
> This is just a weird way to do local dialplan lookups.  Securing the 
> dialplan with this switch in use is no different than we have discussed 
> so far.
> 
> 3) DUNDi Switch
> 
> This is another remote dialplan lookup method, but amongst a peer to 
> peer network.  Similar to IAX2, the only problem that exists is when the 
> call is forwarded over SIP, IAX2, etc. to a remote box and dialplan 
> executes.  The remote dialplans must be secured.
> 
> 4) Realtime Switch
> 
> This allows dialplan lookups from a realtime backend.  The application 
> arguments in the database must be secured just as if they were written 
> in extensions.conf.
> 
> 
> In summary, I don't think the usage of a switch introduces any new 
> elements to the problem.  The end result is still a vulnerability when 
> you're accepting VoIP calls via some method, and the dialplan must be 
> secure.  Am I missing anything?

Well, with the IAX2 switch, it's not very clear that we're sending EXTEN.  Not the DUNDI one either. For the sake of clarity, I think we need to explain these a bit better.

[dundi-e164-switch]
;
; Just a wrapper for the switch
;
switch => DUNDi/e164

[iaxprovider]
;switch => IAX2/user:[key]@myserver/mycontext


In the extensions.conf.sample we just include these - we should propably have a filter before that to show how you can apply a filter BEFORE using a switch - catch all in the incoming context, filter and forward to a new incoming context where contexts like these are used. 

For DUNDI, there is a matching process that matches on various parts and it's not likely that we will risk much. I think other people know this protocol better and can evaluate.

For IAX2 I guess the current EXTEN is sent for lookups and if we have a open pattern match in the target dialplan we are suddenly the attacker AND the attacked.

I think the example should be updated.

/O