[asterisk-dev] Dialstring injection - security advisory release?

[Olle E. Johansson]

11 feb 2010 kl. 22.35 skrev Tilghman Lesher:

>> 
>> I'd much rather see '&' being disallowed in a request by default with an
>> option to allow it.
> 
> That violates the SIP specification, and we'd get reamed for it.  I know this
> doesn't concern you, as long as it prevents you from having to do any
> work.
We just have to support all URI's acceptable by the SIP and the IAX2 specification.

oej at edvina.net is an acceptable username part of a SIP uri (sip:oej at edvina.net@tilghman.com), so the @ is also a valid character, which may harm IAX2 dialstrings as it separates the extension from the context. This is NOT just about SIP dialstrings - it's about all the separator characters in ALL dial strings in ALL channel drivers. 

The ones I can clearly identify here is @ / & :  - we might have a few more.

One cause of this issue is that the dot in patterns swallow everything, including these characters. The problem is extensions like these:

[sip-incoming]
exten => _X.,1,dial(IAX2/${EXTEN})

If we add a replacement for the dot that does not match these dialstring separator characters we can make it easier to update dialplans than forcing users to add a FILTER function call.

I suggest that we do this:

- Add an option in extensions.conf general section "DOTDIALSEPARATORFILTER= yes | no". If yes, single dot does not match these characters and the extension ends up being invalid.

- Add a match pattern called doubledot that does not match on these. Single dot keeps it's old meaning and users can add an extra dot to the extension to force a filter process to happen. With this, we can have both the single dot and the double dot in the same dialplan and thus handle strange characters in the extension if we want this feature - it can be useful.

[sip-incoming]
exten => _X..,1,dial(IAX2/${EXTEN})

This extension would NOT match an extension being "tilghman&johansson/are/stubborn at developers"

SUMMARY:
----------------
We can NOT change the behaviour of existing dialplans - so let's stop discussing that. It's against all policys and unless you have served in the bug tracker for a few years you don't know what you're speaking about when you suggest such a change. We've done it and we've been punished :-)

We can however ADD functionality to existing releases pending Russell's approval and if we all consider it is something we need to make Asterisk work better out there. I do think this is a needed addition of functionality.

We can ALL of us educate the Asterisk community and issue a security advisory paper about this, and why they have to audit and possibly change their dialplans.

I do propose the above changes, as well as reviewing our sample extensions conf and adding the new features to the CHANGES, UPDATE, README and SECURITY documents - hoping that admins will at least read one.

/O