Yes that's cool! :)
l.
2010/2/17 Miguel Molina
> Ok, if I get it the simplest workaround would be changing this:
>
> exten => _X.,1,Dial(SIP/${EXTEN})
>
> To this:
>
> exten => _X.,1,Dial(SIP/${FILTER(0123456789,${EXTEN})})
>
> If you're intended to receive only numbers from the dialstring, rig
That's what I've started doing.
Thanks,
--Warren Selby
On Feb 17, 2010, at 8:29 AM, Miguel Molina
wrote:
> Lenz Emilitri escribió:
>>
>> Ok but this is available today and works fine, so it can be used as a
>> zero day replacement. Any syntax change is welcome but will take time
>> until it
Lenz Emilitri escribió:
>
> Ok but this is available today and works fine, so it can be used as a
> zero day replacement. Any syntax change is welcome but will take time
> until it gets in a public release and does not save you the hassle to
> change the dialplans anyway - unless you implement
While we continue discussing all possible solutions to this and build an
expanding knowledgebase, I would like to repeat myself and kindly ask everyone
that blogs, twitters, talks and teaches about Asterisk to please spread the
word and the links. Later today, there will be an official Asterisk
Ok but this is available today and works fine, so it can be used as a zero
day replacement. Any syntax change is welcome but will take time until it
gets in a public release and does not save you the hassle to change the
dialplans anyway - unless you implement it as a default behaviour at the SIP
On Tue, Feb 16, 2010 at 6:28 PM, meetmecall wrote:
> I didn't know about the function but from what I understand from the "show
> function FILTER" output it doesn't validate a string but it cleans the
> string from not allowed characters. So TRIM(1234567890,01243567&505) results
> in 0124356750
I didn't know about the function but from what I understand from the
"show function FILTER" output it doesn't validate a string but it
cleans the string from not allowed characters. So
TRIM(1234567890,01243567&505) results in 01243567505. If the length
of the output string is shorter then
On Tue, Feb 16, 2010 at 4:38 PM, meetmecall wrote:
> I have read the posts about the security issue and from what I
> understand there should be a check to make sure that the characters
> used are actually allowed. I wrote a very straightforward and not so
> rocket science kind of macro that will
that goes to an ivr. Can this be a security bridge?
>
>
>
> --- On Mon, 2/15/10, Tony Mountifield wrote:
>
>> From: Tony Mountifield
>> Subject: Re: [asterisk-users] Important security alert: update your
>> dialplans now!
>> To: asterisk-users@lists.d
t
include => test-agi
include => menu
that goes to an ivr. Can this be a security bridge?
--- On Mon, 2/15/10, Tony Mountifield wrote:
> From: Tony Mountifield
> Subject: Re: [asterisk-users] Important security alert: update your dialplans
> now!
> To: asteri
I have read the posts about the security issue and from what I
understand there should be a check to make sure that the characters
used are actually allowed. I wrote a very straightforward and not so
rocket science kind of macro that will do the job I guess. Just two
parameters, one with th
Hi!
> But, there's no reason we can't add other matching chars for
> handy things. A = alpha chars Y = alphanum chars, G = Graphical chars,
Pretty please!
Philipp
--
_
-- Bandwidth and Colocation Provided by http://www.api-di
On Tue, Feb 16, 2010 at 10:53:16AM -0700, Steve Murphy wrote:
> (is there some escape mech in the syntax to let you say \NA\NCY? I
> haven't checked).
[N]A[N]CY . Or, if we have it your way, [N][A][N]C[Y]
> But, there's no reason we can't add other matching chars
> for handy things. A = alpha
On Tue, Feb 16, 2010 at 3:01 AM, Olle E. Johansson 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
> wrote:
> >>
> >>> Yes but in any case you can enter all of the string
On Tue, Feb 16, 2010 at 1:43 AM, Tzafrir Cohen wrote:
> On Mon, Feb 15, 2010 at 09:40:31AM -0700, Steve Murphy wrote:
> > On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri
> wrote:
> >
> > > Yes but in any case you can enter all of the strings that reasonably
> match
> > > - even if you have variabl
Tilghman Lesher wrote:
> On Monday 15 February 2010 18:01:11 Vinícius Fontes wrote:
He probably means AgentCallbackLogin
>>> While it has been deprecated, that hasn't been removed, either. If
>>> an
>>> enterprising person would like to try to fix it, I don't have an
>>> objection.
>> Wasn't
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 wrote:
>>
>>> Yes but in any case you can enter all of the strings that reasonably match
>>> - even if you have variable-length numbers, y
On Mon, Feb 15, 2010 at 09:40:31AM -0700, Steve Murphy wrote:
> On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri 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 num
On Monday 15 February 2010 18:01:11 Vinícius Fontes wrote:
> > > He probably means AgentCallbackLogin
> >
> > While it has been deprecated, that hasn't been removed, either. If
> > an
> > enterprising person would like to try to fix it, I don't have an
> > objection.
>
> Wasn't AgentCallBackLogin(
> > He probably means AgentCallbackLogin
>
> While it has been deprecated, that hasn't been removed, either. If
> an
> enterprising person would like to try to fix it, I don't have an
> objection.
>
Wasn't AgentCallBackLogin() removed in 1.6.1?
--
_
On Monday 15 February 2010 09:05:33 Michiel van Baak wrote:
> On 08:48, Mon 15 Feb 10, Tilghman Lesher wrote:
> > On Monday 15 February 2010 03:37:24 Rob Hillis wrote:
> > > On 02/15/10 20:00, Randy R wrote:
> > > > Olle, this may be a stupid question, but shouldn't a native santitize
> > > > funct
In article <699ee941002150033t7c6e1be5xdba76cb0f68d5...@mail.gmail.com>,
Lenz Emilitri wrote:
> -=-=-=-=-=-
> -=-=-=-=-=-
>
> Or one could simply rewrite to:
>
> [incoming-from-voip]
> exten => XXX,1,Dial(${ext...@incoming-from-voip-old)
> exten => ,1,Dial(${ext...@incoming-from-voip
On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri 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
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.
BTW,
On 08:48, Mon 15 Feb 10, Tilghman Lesher wrote:
> On Monday 15 February 2010 03:37:24 Rob Hillis wrote:
> > On 02/15/10 20:00, Randy R wrote:
> > > Olle, this may be a stupid question, but shouldn't a native santitize
> > > function be urgently added to the code base in all versions or change
> > >
15 feb 2010 kl. 10.00 skrev Randy R:
> On Mon, Feb 15, 2010 at 9:51 AM, Olle E. Johansson wrote:
>>> To avoid extensive rewriting and fix the current issue.
>> That works in countries where you have fixed-length numbers. Unfortunately,
>> not every dialplan works that way, so that can't be a ge
On 02/15/10 20:00, Randy R wrote:
>
> Olle, this may be a stupid question, but shouldn't a native santitize
> function be urgently added to the code base in all versions or change
> the dialplan compîler to ignore dangerous characters?
Whilst I agree with this, the unfortunate attitude we seem to
On Mon, Feb 15, 2010 at 9:51 AM, Olle E. Johansson wrote:
>> To avoid extensive rewriting and fix the current issue.
> That works in countries where you have fixed-length numbers. Unfortunately,
> not every dialplan works that way, so that can't be a generic advice even
> though it may solve you
15 feb 2010 kl. 09.33 skrev Lenz Emilitri:
> Or one could simply rewrite to:
>
> [incoming-from-voip]
> exten => XXX,1,Dial(${ext...@incoming-from-voip-old)
> exten => ,1,Dial(${ext...@incoming-from-voip-old)
> exten => X,1,Dial(${ext...@incoming-from-voip-old)
> exten => XXX
Or one could simply rewrite to:
[incoming-from-voip]
exten => XXX,1,Dial(${ext...@incoming-from-voip-old)
exten => ,1,Dial(${ext...@incoming-from-voip-old)
exten => X,1,Dial(${ext...@incoming-from-voip-old)
exten => XX,1,Dial(${ext...@incoming-from-voip-old)
[incoming-
On Sun, Feb 14, 2010 at 11:22:12AM -0800, Kyle Kienapfel wrote:
> strip_ampersands(${EXTEN})?
You forget other potentially harmful characters.
&@:,/|
And maybe others.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.co...@xorcom.com
+972-50-7952406 mailto:t
14 feb 2010 kl. 21.04 skrev Steve Edwards:
> On Sun, 14 Feb 2010, Kyle Kienapfel wrote:
>
>> strip_ampersands(${EXTEN})?
>
> (sip.conf)
>
> [general]
> allow-characters= all
> disallow-characters = "&"
>
> [example-did-provider]
> allow-characters
While I like these solutions, they should never be substituting a good
secure dialplan.
On Sun, Feb 14, 2010 at 3:04 PM, Steve Edwards
wrote:
> On Sun, 14 Feb 2010, Kyle Kienapfel wrote:
>
>> strip_ampersands(${EXTEN})?
>
> (sip.conf)
>
> [general]
> allow-characters = all
>
On Sun, 14 Feb 2010, Kyle Kienapfel wrote:
> strip_ampersands(${EXTEN})?
(sip.conf)
[general]
allow-characters= all
disallow-characters = "&"
[example-did-provider]
allow-characters= "[:numeric:]"
--
Thanks in advance,
--
strip_ampersands(${EXTEN})?
On Sun, Feb 14, 2010 at 10:56 AM, C F wrote:
> On Sun, Feb 14, 2010 at 3:26 AM, Olle E. Johansson wrote:
>>
>> 14 feb 2010 kl. 03.25 skrev C F:
>>
>>> Excellent and very informative article, Thanks Olle.
>> You're welcome.
>>>
>>> I ran thru lots of my dialplans now q
On Sun, Feb 14, 2010 at 3:26 AM, Olle E. Johansson wrote:
>
> 14 feb 2010 kl. 03.25 skrev C F:
>
>> Excellent and very informative article, Thanks Olle.
> You're welcome.
>>
>> I ran thru lots of my dialplans now quickly to see if I have a catch
>> all exten anywhere. I couldn't find any that are
On Sun, Feb 14, 2010 at 2:30 AM, Tzafrir Cohen wrote:
> On Sat, Feb 13, 2010 at 09:25:01PM -0500, C F wrote:
>> Excellent and very informative article, Thanks Olle.
>>
>> I ran thru lots of my dialplans now quickly to see if I have a catch
>> all exten anywhere. I couldn't find any that are access
14 feb 2010 kl. 03.25 skrev C F:
> Excellent and very informative article, Thanks Olle.
You're welcome.
>
> I ran thru lots of my dialplans now quickly to see if I have a catch
> all exten anywhere. I couldn't find any that are accessible
> unauthenticated, I always declare all fixed length exte
On Sat, Feb 13, 2010 at 09:25:01PM -0500, C F wrote:
> Excellent and very informative article, Thanks Olle.
>
> I ran thru lots of my dialplans now quickly to see if I have a catch
> all exten anywhere. I couldn't find any that are accessible
> unauthenticated, I always declare all fixed length ex
Excellent and very informative article, Thanks Olle.
I ran thru lots of my dialplans now quickly to see if I have a catch
all exten anywhere. I couldn't find any that are accessible
unauthenticated, I always declare all fixed length extensions using
patterns the exception being international calls
Friends,
Last week, Hans Petter Selansky alerted us of a potential security issue in all
releases of Asterisk. In fact, it doesn't involve the code, but the most common
way to construct dialplans. If you have something like this in your Asterisk,
you need to update your dialplans:
[incoming-fr
41 matches
Mail list logo