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

[Benny Amorsen]

Klaus Darilion <klaus.mailinglists at pernau.at> writes:

> I think you have to differ with script languages and other languages. 
> Script languages which do string substitution before starting the 
> function are vulnerable, e.g.:
>
> #!/usr/bin/php
> <?php
>    $exten="%";
>    printf("%s%d\n",$exten,134);
>    printf($exten."%d\n",134);
> ?>
>
> results in:
> ./test.php
> %134
> %d

Isn't that particular example just showing that printf is a lousy
function? You couldn't do

$exten=",";

to trick php into calling printf with an empty first argument (I just
checked, PHP just considers the , as part of the string and prints
,134). Perl is the same in this regard, it doesn't try to parse the
contents of a variable unless you ask it explicitly to do so. That's the
kind of thing you can do in Asterisk dial plans. E.g. you'd think that

exten => _X!,Goto(${EXTEN})

would let you jump to any number or label in the current context
depending on ${EXTEN}. What you probably wouldn't expect is $EXTEN being
1menu,1234,1 and taking you to a completely different context. In
almost all programming languages, the whole contents of the variable
would be considered one unit, not split into 3.

Admittedly noone sane would write the above code as it serves very
little purpose, but I bet the behaviour would surprise almost everyone
who hasn't spent time dealing with the same sort of issues in Unix shell
programming. At least Bash gives you the tools to deal with its
brokenness; you can always slap quotes around a variable and know that
nothing can escape from those. No such luck with Asterisk dialplan,
where the handling of quotes and escapes can most politely be described
as "unique".


/Benny