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

Klaus Darilion klaus.mailinglists at pernau.at
Fri Feb 12 03:43:30 CST 2010



Am 11.02.2010 21:58, schrieb Matt Riddell:
> On 12/02/10 8:10 AM, Tilghman Lesher wrote:
>>> It is however reasonable to expect php to protect itself and it does. No
>>> variable or array element can cause code to be injected in php. I wonder
>>> whether the php team would issue a best practice document if it was
>>> found that, when passed to a function, a string containing for example:
>>>
>>> mystring");exec("poweroff");
>>>
>>> caused the host to poweroff . I am hopeful that they would issue a
>>> security alert with mitigation advice but that they would also fix php.
>>
>> On the contrary, this is more akin to a PHP programmer including input text
>> from a random user on his page, without defanging any potential
>> embedded Javascript.  This is not a vulnerability that the PHP language can
>> fix, but the PHP programmer is responsible for taking action.
>
> I'd much rather see '&' being disallowed in a request by default with an
> option to allow it.

I wonder why anybody talkes about & only. What about , | / ... Isn't it 
that all characters which are used by Asterisk commands or functions are 
potentially harmful? In this case all such characters which are used by 
Asterisk apps/funcs needs to be escaped.

For external applications (SQL, exec, AGI ...) the script writer has to 
take itself.

regards
klaus

>
> The problem is recoding thousands of lines of dialplan code.
>
> The other option would be a switch in asterisk.conf which changes the
> wildcard to only match a-z, A-Z, 0-9.
>
> That way you could mitigate most issues straight away with a one line
> change, and those people who need to accept $#%^%$^@voip.com could deal
> with the FILTER function.
>
> Although this has always been here, it seems to me to be the same as a
> newly introduced feature (discovered).
>
> If one were to add a feature to 1.4 that required everyone to rewrite
> their dialplan it would be frowned upon.
>
> If it was a feature, surely it would be suggested that the one line
> change, defaulting to on in asterisk.conf would be preferred.
>



More information about the asterisk-dev mailing list