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

[Klaus Darilion]

Am 23.02.2010 08:29, schrieb Pavel Troller:
>>
>>
>> Am 22.02.2010 20:01, schrieb Atis Lezdins:
>>> On Mon, Feb 22, 2010 at 4:38 PM, Nick Lewis<Nick.Lewis at atltelecom.com>   wrote:
>> ..
>>>> I accept that such a change may add work for those dialplan programmers
>>>> that use 'strange' characters in their extensions but I suspect that it
>>>> may reduce the work of most dialplan programmers who do not use
>>>> 'strange' characters in their extensions and are just wanting to make
>>>> their dialplans secure
>>>>
>>>
>>> Isn't the problem solved by using exact dialplan patterns only
>>> allowing numbers or alpha-numeric characters? I have all calls going
>>> through strict mask pattern, for example:
>>>
>>> _XXXXX =>   internal calls
>>> _18XXXXXXXXX =>   toll free calls
>>>
>>> etc.
>>>
>>> The problem is only when somebody uses mask "_X." everywhere. As for
>>> security "." could change meaning to "any alpha-numeric character"
>>> (with setting to reverse functionality for those who really want weird
>>> extensions), plus introduce a new symbol (let's assume question mark
>>> "?") to match zero or more digits only. So, samples and everything
>>> else could use _X? which is safe at very beginning. Additionally if
>>> necessary backward compatible any-character could be allowed by new
>>> symbol.
>>>
>>> So:
>>>
>>> _X? =>   Dial(SIP/${EXTEN}) ; - safe, accepts only digits
>>> _X. =>    Dial(SIP/${EXTEN}) ; - safe, accepts only [0-9a-zA-Z#*]
>>> _X* =>    Dial(SIP/${FILTER(${EXTEN})}) ; - also safe, bad characters
>>> are filtered out
>>> _X* =>    Dial(SIP/${EXTEN}) ; - not safe. Documentation should issue
>>> warning next to this, asking to re-consider and use only in
>>> combination with FILTER()
>>
>> This was already suggested by several other people, but not yet
>> implemented :-(
>>
>> regards
>> klaus
>>
> Hi!
>    Please also don't forget, that now we have two pattern matchers, i.e.
> ".", which collects digits, and "!", which triggers as soon as the match is
> complete, so we need TWO new symbols for their "safe" equivalents.

In addition to previous mail: IMO we need a wildcard which matches 0 or 
more of the previously pattern. (see older discussion)

regards
klaus