[asterisk-dev] Dialplan oddities with recent Asterisk ?

[Pavel Troller]

> > Is '&' ever an acceptable character in a SIP URI? If so, Asterisk
> needs
> > to escape these things. If not, would it not be prudent to have the
> > dialplan parser simply not accept invalid characters?
> 
> '&' is an unreserved character in the relevant portion of a SIP URI.
> Even if it where not an unreserved character it would still be
> representable in an encoded form that would be decoded before chan_sip.c
> hands the extension to the pbx. In general the pbx can expect chan_sip.c
> to provide extensions containing any ascii chars (even unprintable ones)
> except CR and LF.
> 
> -- N_L
> 

Hi!
  I've just verified that by calling a "number", for example in the form of
12345&DAHDI/g1/0012125551212, users can call a destination, which would
be normally unreachable from their context, and even access a trunk group,
which is absolutely not allowed for them to access. It's really a good to
read about it here, because it can be a serious vulnerability. I understand
that my dialplan is fully responsible for this, so now I'm trying to implement
some checks to prevent such hacks.
  I was looking at the Filter() function and it seems that I would like
an inverse implementation - not to pass allowed characters only, but to
filter out disallowed ones - for example, I would like to permit a large
number of various characters in the dial string, but definitively to filter
out '&' and maybe a few others, for which the current Filter() implementation
doesn't seem to be ideal. What about patching it to allow this "blacklist
filtering" by putting a ~ or ^ as the first character of the char list ?

With regards, Pavel