[asterisk-users] Important security alert: update your dialplans now!

[Steve Murphy]

On Tue, Feb 16, 2010 at 3:01 AM, Olle E. Johansson <oej at edvina.net> wrote:

>
> 16 feb 2010 kl. 09.43 skrev Tzafrir Cohen:
>
> > On Mon, Feb 15, 2010 at 09:40:31AM -0700, Steve Murphy wrote:
> >> On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri <lenz.loway at gmail.com>
> wrote:
> >>
> >>> Yes but in any case you can enter all of the strings that reasonably
> match
> >>> - even if you have variable-length numbers, you will be able to
> determine
> >>> that a valid number be between 5 and 15 characters - or likely 2 to 20,
> all
> >>> numbers. A number of 156 characters is very likely to be a problem.
> >>>
> >>
> >> This is probably a stupid idea, because it could only be implemented in
> >> trunk, and won't help with current implementations,
> >> and I suggested it a long time ago already when I did the fast pattern
> >> matching code, but I don't THINK it would be all that
> >> hard to offer SOME regex syntax in patterns to help reduce the impact of
> >> these kinds of problems.
> >>
> >> Like using:
> >>
> >> [incoming-from-voip]
> >> exten => _X\{7-10\},1,Dial(${EXTEN}@incoming-from-voip-old)
> >>
> >> instead of :
> >>
> >> [incoming-from-voip]
> >> exten => XXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)
> >> exten => XXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)
> >> exten => XXXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)
> >> exten => XXXXXXXXXX,1,Dial(${EXTEN}@incoming-from-voip-old)
> >>
> >> I put the \'s in front of the {}'s because we probably wouldn't want to
> >> change the
> >> behavior of exact matching, and there's some precedent for using such
> stuff
> >> in some implementations of regex, where \< matches the beginning of a
> word,
> >> etc.
> >>
> >> and, of course there would be the shorthand variants \{7-\} for seven or
> >> more; \{-10\} for 1-10.
> >> Some might argue 0-10. Whatever.
> >>
> >> I THINK this could be implemented in both the fast pattern matcher and
> the
> >> current slow one. I know it wouldn't be that bad to do in the fast
> pattern
> >> matcher.
> >> I hadn't really given the slow one (the current one) much thought.
> >
> > I think it would be very useful. One small point:
> >
> > The '.' is short. This helps making it pupular. X\{1-\} is much less
> > so.
> >
> > Another thing that I think would help: an equivalent of perl's \w:
> > something similar to 'X', but also matches letters. This is syntactic
> > sugar, but we need such sugar for readable dialplans.
> >
> Leif and I had a proposal years ago for an "alphaexten" that used perl
> regexps.
>
>
Yes, I know that many have proposed full regex  and regex-like extensions
for
the dialplan patterns, but there's one big rub. The current pattern matcher
is light and
fast compared to a full regex matcher.  The restrictions on constructs make
it a fairly
fast linear matcher without any loops or recursive behavior to slow it down.
We can currently use
rules to quantify the "best match" that makes it fairly predictable, and the
work on a
fast pattern matcher (O(log(pattern length))  instead of  O((num
patterns)^2) was possible.

But, when you move to full regex approaches, you lose all those nice
properties. You'd have
to move to a 'best match first' sort of strategy,  so you can move from a
O(n^2) type scenario,
and you lock yourself into an O(n^2/2) scenario. For large dialplans on a
busy system, you are
totally screwed, without any hope of improving the situation.

I tried in times past to propose a subset of regex patterns that would still
leave us with fast
pattern matching....

murf

/O
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-users
>



-- 
Steve Murphy
ParseTree Corp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20100216/6c60c34a/attachment.htm