[asterisk-dev] Dialstring injection - security advisory release?
Klaus Darilion
klaus.mailinglists at pernau.at
Mon Feb 15 12:03:25 CST 2010
Am 15.02.2010 17:48, schrieb 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=",";
Ok, I see what you mean.
> 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})
I think the problem is, that in extensions.conf every application and
command have just one parameter. Splitting of this parameter in the
applications parameters is done in the application, not before calling
the application. Anyway, even if it would be done before calling the
application, it only protects attacks using the ',' character.
regards
klaus
>
> 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
>
>
More information about the asterisk-dev
mailing list