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

[Tilghman Lesher]

On Thursday 11 February 2010 14:58:49 Matt Riddell wrote:
> 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.

That violates the SIP specification, and we'd get reamed for it.  I know this
doesn't concern you, as long as it prevents you from having to do any
work.

> 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's a change in behavior, which is strictly forbidden by our release
policy.  It has the potential to break thousands of dialplans with no warning.
I can't take responsibility for that, and nobody else will, so it's off the
table.

> 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.

Yes, this is the problem.  NOBODY wants to have to change anything, and the
people affected by this will have the exact opposite reaction to your
suggestion -- don't break their dialplans; just make it optional, with the
default being on.

We CANNOT satisfy everybody with any change here, and therefore we must
stick to pre-established policy as to how we proceed.  That's at least
expected by everybody, and while I'm sure you'd prefer a fix-it-and-forget-it
solution, that is not warranted by the situation.

> Although this has always been here, it seems to me to be the same as a
> newly introduced feature (discovered).

That borders on the ridiculous.  I'm sure I could find some feature in
Asterisk that has been around since 1.0 that you don't know about.  That
doesn't make it a new feature, just something that you've failed to learn
thus far.  Our proposed solution is education in the form of a best practices
document.

> If one were to add a feature to 1.4 that required everyone to rewrite
> their dialplan it would be frowned upon.

That's the first thing you've said that we agree 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.

But it's not a feature, nor is it a bug in the dialplan.  Rather, it's a bug
in certain people's dialplans, which should be fixed.  Hence, educating
people about the potential is the right way forward.

-- 
Tilghman Lesher
Digium, Inc. | Senior Software Developer
twitter: Corydon76 | IRC: Corydon76-dig (Freenode)
Check us out at: www.digium.com & www.asterisk.org