[asterisk-dev] Dialstring injection - security advisory release?
Zoa
zoachien at securax.org
Mon Feb 22 06:45:11 CST 2010
Kevin P. Fleming wrote:
> Nick Lewis wrote:
>
>
>> My point is that it is not up to the programmer to deal with php
>> injection in php. This is up to the php language designer. Similarly I
>> think it is up to the dialplan language designer to deal with dialplan
>> injection in the dialplan language.
>>
>> If the pbx were to escape all the characters that are part of the syntax
>> of the dialplan language as soon as the variable containing them was
>> passed from a channel then the language would be as secure as other
>> languages
>>
>
> Unfortunately, though, the issues here are *not* technically part of the
> dialplan language, they are part of the syntax of applications. The
> language syntax includes separation of parameters to applications, and
> so such escaping could certainly be expected to handle ',' (and '|' in
> older versions), but that's as far as the *language* goes. The issue
> that brought this to light is explicitly related to the Dial()
> application and its sub-parsing of arguments. While this is very common,
> and there are other applications that also use '&' for sub-parsing, none
> of them are vulnerable to the sort of attacks that Dial() is, and so
> escaping this character for them is just wasteful and inefficient.
>
> In addition, Dial has at least one *other* character that is vulnerable
> to this sort of thing, which is '^', used for separating arguments to
> macros it is supposed to run. If one of the arguments to be supplied is
> extracted from a variable that the user can supply the value for, then
> they can directly influence the remaining arguments to the macro. Again,
> though, this is only a vulnerability in Dial() (and other applications
> that support the same mechanism, like Queue()).
>
> Given that, I really can't see the justification for a massive,
> system-wide audit of all possible characters that might be able to be
> mis-used, and a subsequent automatic escaping of them, necessitating
> significant dialplan changes for users upgrading to a version containing
> these changes.
>
>
I think there might also be a possibility for abuse with %40 in certain
scenarios.
Zoa
More information about the asterisk-dev
mailing list