Re: [asterisk-users] Important security alert: update your dialplans now!
Yes that's cool! :)
l.
2010/2/17 Miguel Molina mmol...@millenium.com.co
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, right?
See http://www.voip-info.org/wiki/view/Asterisk+func+filter
Regards,
--
Loway - home of QueueMetrics - http://queuemetrics.com
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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 driver level. And I got a feeling that most people will simply not bother learning regexps You could just as reasonably write a script to do the check, or run a check in the dialplan itself, or change Asterisk. l. 2010/2/15 Steve Murphy m...@parsetree.com On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri lenz.lo...@gmail.comwrote: 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. -- Loway - home of QueueMetrics - http://queuemetrics.com -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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 Security Advisory published on http://www.asterisk.org. Take this as an oppurtunity to repeat yourselves and make sure that no Asterisk admin anywhere talking any language can miss this information. If you are involved in a third-party project or commercial company that builds a GUI or anything that manages Asterisk dialplans, please make sure that your users are aware of this and that your project also releases information about this and if needed, updates your platform. If you are a distributor of Asterisk-related equipment, please don't hesitate to inform your resellers and customers. Let's use all the resources we have to make sure that we limit the damage that this issue causes. And thank you to all of you that has already been forwarding information about this issue. Best regards, /Olle My original alert is to be found here: http://lists.digium.com/pipermail/asterisk-users/2010-February/244721.html -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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 it as a default
behaviour at the SIP driver level. And I got a feeling that most
people will simply not bother learning regexps
You could just as reasonably write a script to do the check, or run a
check in the dialplan itself, or change Asterisk.
l.
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, right?
See http://www.voip-info.org/wiki/view/Asterisk+func+filter
Regards,
--
Ing. Miguel Molina
Grupo de Tecnología
Millenium Phone Center
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
That's what I've started doing.
Thanks,
--Warren Selby
On Feb 17, 2010, at 8:29 AM, Miguel Molina mmol...@millenium.com.co
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 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 driver level. And I got a feeling that most
people will simply not bother learning regexps
You could just as reasonably write a script to do the check, or run a
check in the dialplan itself, or change Asterisk.
l.
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, right?
See http://www.voip-info.org/wiki/view/Asterisk+func+filter
Regards,
--
Ing. Miguel Molina
Grupo de Tecnología
Millenium Phone Center
--
_
-- 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
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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.lo...@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(${ext...@incoming-from-voip-old)
instead of :
[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)
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.
--
Tzafrir Cohen
icq#16849755 jabber:tzafrir.co...@xorcom.com
+972-50-7952406 mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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.lo...@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(${ext...@incoming-from-voip-old)
instead of :
[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)
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.
/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
Re: [asterisk-users] Important security alert: update your?dialplans now!
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 AgentCallBackLogin() removed in 1.6.1? I didn't think we did, but apparently so. I wrote a document on how to do this in the dialplan. It's in the doc/ subdirectory in Asterisk 1.6.2. Leif. -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
On Tue, Feb 16, 2010 at 1:43 AM, Tzafrir Cohen tzafrir.co...@xorcom.comwrote:
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.lo...@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(${ext...@incoming-from-voip-old)
instead of :
[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)
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.
Very true, but the added syntax would not replace '.'. And they mean two
different things. X\{1-\} would mean one or more numbers, . means
any number of any character.
Heck, besides N\{2-4\}, Z\{3-7\}, I guess we could even do .\{2-100\}, which
could mean 'match everything at the end of the string, but only if there's 2
to
100 of them', or something like that. Whatever is the most handy.
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.
Could be done, but it ends up getting in the way of exact matching;
right now, using X,N,Z keeps you from exact matching those characters,
(is there some escape mech in the syntax to let you say \NA\NCY? I
haven't checked). But, there's no reason we can't add other matching chars
for handy things. A = alpha chars Y = alphanum chars, G = Graphical chars,
whatever. We just have to watch those backslashes, because if we use them as
an escape to mean literals in some situations, and as a notation to mean a
special function in others, then it starts getting confusing real quick.
But all this kind of thing Could Be Done.
murf
--
Tzafrir Cohen
icq#16849755
jabber:tzafrir.co...@xorcom.comjabber%3atzafrir.co...@xorcom.com
+972-50-7952406 mailto:tzafrir.co...@xorcom.com
http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir
--
_
-- 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
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
On Tue, Feb 16, 2010 at 3:01 AM, Olle E. Johansson o...@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.lo...@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(${ext...@incoming-from-voip-old)
instead of :
[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)
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
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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 chars Y = alphanum chars, G = Graphical chars, whatever. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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-digital.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Important security alert: update your dialplans now!
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 the allowed characters and one with the string to
check. The allowed characters can be stored in a global variable if
this set has a global character. It is just one extra line in the
dialplan and a little bit extra cpu load.
It is used like this:
exten = _X.,1,Macro(alfa_num_check,1234567890,${EXTEN})
exten = _X.,n,Dial(SIP/315927xx/${EXTEN},40,t)
exten = _X.,n,Hangup()
If not allowed characters are used the call setup will end.
And the actual macro does just have 20 lines of Asterisk code. I'm
sure there will be better solutions in the future but for the short
time this might be useful. A clever scripter might be able to write a
script that scans the dialplan line by line and adds the macro line
above the _.,n,DIAL() lines and adjust the numbering of the line
if needed. I have done some testing and the code in this mail
ishould work, at least it did on my Asterisk box.
Friendly regards,
Erik
[macro-alfa_num_check]
; written by : erik de wild
; company : Tripple-oYour Asterisk migration partner
; e-mail: info at tripple-o.nl
; date : 16 februari 2010
;
; everybody is free to use, improve and modify this code
; as long as credits will be addressed, no costs are charged
; and this header stays with the code.
;
exten = s,1,NoOp(This is a macro to check the content of the ${EXTEN}
variable to cope with the vulnerabilily of number injection)
exten = s,n,Set(ALLOWED_CHARACTERS=${ARG1})
exten = s,n,Set(STRING_TO_CHECK=${ARG2})
exten = s,n,Set(LEN_ALLOWED_CHARACTERS=${LEN(${ALLOWED_CHARACTERS})})
exten = s,n,Set(LEN_STRING_TO_CHECK=${LEN(${STRING_TO_CHECK})})
exten = s,n,Set(COUNTER=0)
exten = s,n(start_loop),SET(CHAR_TO_CHECK=${STRING_TO_CHECK:$
{COUNTER}:1})
exten = s,n,NoOp(Character to check is ${CHAR_TO_CHECK}. This
Character should be in this list of characters - ${ALLOWED_CHARACTERS})
exten = s,n,Set(COUNTER2=0)
exten = s,n,NoOp(character to check: ${CHAR_TO_CHECK}- $
{ALLOWED_CHARACTERS:${COUNTER2}:1})
exten = s,n(start_loop2),GotoIf($[${CHAR_TO_CHECK} = $
{ALLOWED_CHARACTERS:${COUNTER2}:1}]?exit_loop2) ;
exten = s,n,Set(COUNTER2=$[${COUNTER2} + 1])
exten = s,n,GotoIf($[${COUNTER2} = ${LEN_ALLOWED_CHARACTERS}]?
hangup)
; if the character to control is not in the list of allowed
characters then the setup of the call has to stop
exten = s,n,Goto(start_loop2)
exten = s,n(exit_loop2),NoOp(character checked is allowed, go for the
next charachter!!)
exten = s,n,Set(COUNTER=$[${COUNTER} + 1])
exten = s,n,GotoIf($[${COUNTER} = ${LEN_STRING_TO_CHECK}]?
macroexit)
exten = s,n,Goto(start_loop)
exten = s,n(hangup),NoOp(the checked character is not in the allowed
charachter string. Call setup has to stop)
exten = s,n,Hangup()
exten = s,n(macroexit),MacroExit()
On 14 feb 2010, at 00:04, Olle E. Johansson wrote:
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-from-voip]
exten = _X., 1, dial(SIP/${EXTEN})
Many VoIP protocols support a large character set, that may cause
harm in your dialplan
I've written an article about this on my blog, where my summary says:
Because of a conflict between allowed characters in the called
number or name in many VoIP protocols and the way Asterisk handles
channel variables, there is a security risk hidden in many dialplans
based on examples provided over the years by the Asterisk
developers, trainers and community. The primary risk is that by
using an ampersand in the dialstring, a user can access protected
resources or misuse the pbx services. However, this character is not
the only problem, as other characters may cause unexpected or
problematic behaviour.
There will be an Asterisk Security Advisory document coming out from
Digium soon, as well as updated documentation and examples within
the Asterisk source code tree. I strongly advise everyone to follow
these and stay updated. (I have no access to the ASA system myself
and can't generate an official security alert).
For more information about this issue and some code examples of what
I personally currently think are good ways to prevent misuse of your
services, please read my blog article at
http://www.voip-forum.com/?p=241preview=true
Please help us to distribute this message!
Re: [asterisk-users] Important security alert: update your dialplans now!
I have this:
[menu]
exten = _X.,1,answer()
exten = _X.,2,wait(1)
exten = _X.,n,GoTo(ivr,s,1)
[default]
include = record
include = incoming
include = menu
[local-dial]
exten = _1XX,1,Verbose(. In local-dial context, dialing exten: ${EXTEN}
.
exten = _1XX,2,Dial(SIP/${EXTEN},20,tTmkKhHWw)
exten = _1XX,n,voicemail(${EXTEN},u)
exten = _1XX,n,Hangup()
include = agents
include = queue
include = local-iax
include = voicemail
include = timeofday
include = parkedcalls
include = pickup
include = to_client
include = test-agi
include = menu
that goes to an ivr. Can this be a security bridge?
--- On Mon, 2/15/10, Tony Mountifield t...@softins.clara.co.uk wrote:
From: Tony Mountifield t...@softins.clara.co.uk
Subject: Re: [asterisk-users] Important security alert: update your dialplans
now!
To: asterisk-users@lists.digium.com
Date: Monday, February 15, 2010, 11:58 AM
In article 699ee941002150033t7c6e1be5xdba76cb0f68d5...@mail.gmail.com,
Lenz Emilitri lenz.lo...@gmail.com
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-old)
exten =
X,1,Dial(${ext...@incoming-from-voip-old)
exten =
XX,1,Dial(${ext...@incoming-from-voip-old)
[incoming-from-voip-old]
exten = _X., 1, dial(SIP/${EXTEN})
To avoid extensive rewriting and fix the current
issue.
l.
Don't forget you still need the underscore to make X
magic:
exten =
_XXX,1,Dial(${ext...@incoming-from-voip-old)
etc.
Tony
--
Tony Mountifield
Work: t...@softins.co.uk
- http://www.softins.co.uk
Play: t...@mountifield.org
- http://tony.mountifield.org
--
_
-- 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
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
I have tried to replicate this, but with no luck. If I use a SIP-client
that supports '', I still get a reject from asterisk.
I am writing a filter for lua (pbx_lua), but it's a bit hard when I
cannot reproduce and test this. I've tried with both 1.6.1-series and
1.6.2. Any ideas?
Thanks,
Tommy
Landy Landy skrev:
I have this:
[menu]
exten = _X.,1,answer()
exten = _X.,2,wait(1)
exten = _X.,n,GoTo(ivr,s,1)
[default]
include = record
include = incoming
include = menu
[local-dial]
exten = _1XX,1,Verbose(. In local-dial context, dialing exten: ${EXTEN}
.
exten = _1XX,2,Dial(SIP/${EXTEN},20,tTmkKhHWw)
exten = _1XX,n,voicemail(${EXTEN},u)
exten = _1XX,n,Hangup()
include = agents
include = queue
include = local-iax
include = voicemail
include = timeofday
include = parkedcalls
include = pickup
include = to_client
include = test-agi
include = menu
that goes to an ivr. Can this be a security bridge?
--- On Mon, 2/15/10, Tony Mountifield t...@softins.clara.co.uk wrote:
From: Tony Mountifield t...@softins.clara.co.uk
Subject: Re: [asterisk-users] Important security alert: update your
dialplans now!
To: asterisk-users@lists.digium.com
Date: Monday, February 15, 2010, 11:58 AM
In article 699ee941002150033t7c6e1be5xdba76cb0f68d5...@mail.gmail.com,
Lenz Emilitri lenz.lo...@gmail.com
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-old)
exten =
X,1,Dial(${ext...@incoming-from-voip-old)
exten =
XX,1,Dial(${ext...@incoming-from-voip-old)
[incoming-from-voip-old]
exten = _X., 1, dial(SIP/${EXTEN})
To avoid extensive rewriting and fix the current
issue.
l.
Don't forget you still need the underscore to make X
magic:
exten =
_XXX,1,Dial(${ext...@incoming-from-voip-old)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREKAAYFAkt7ICEACgkQ573V05EH/pZ9ZwCg0VOERk24lbfpEiJLCwso5h0X
UokAoKMlr8lEHBYD95YEiWNvVBF7mWbj
=t0Wq
-END PGP SIGNATURE-
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
On Tue, Feb 16, 2010 at 4:38 PM, meetmecall i...@meetmecall.nl 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 do the job I guess. Just two parameters, one with the allowed characters and one with the string to check. The allowed characters can be stored in a global variable if this set has a global character. It is just one extra line in the dialplan and a little bit extra cpu load. Doesn't the built-in function FILTER() already do this? *CLI core show function FILTER *CLI -= Info about function 'FILTER' =- [Synopsis] Filter the string to include only the allowed characters [Description] Permits all characters listed in allowed-chars, filtering all others outs. In addition to literally listing the characters, you may also use ranges of characters (delimited by a '-' Hexadecimal characters started with a '\x'(i.e. \x20) Octal characters started with a '\0' (i.e. \040) Also '\t','\n' and '\r' are recognized. NOTE: If you want the '-' character it needs to be prefixed with a '\' [Syntax] FILTER(allowed-chars,string) [Arguments] Not available [See Also] Not available -- Thanks, --Warren Selby http://www.selbytech.com -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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,01243567505) results in 01243567505. If the length of the output string is shorter then the input string the call setup should stop because not allowed characters were stripped. With some extra lines TRIM() will do as good as the macro I guess. You can add some lines so someone trying to perform number injection will be connected with an answering machine and be requested to leave name and phone number ;-) Erik On 17 feb 2010, at 00:41, Warren Selby wrote: On Tue, Feb 16, 2010 at 4:38 PM, meetmecall i...@meetmecall.nl wrote: Doesn't the built-in function FILTER() already do this? *CLI core show function FILTER *CLI -= Info about function 'FILTER' =- [Synopsis] Filter the string to include only the allowed characters [Description] Permits all characters listed in allowed-chars, filtering all others outs. In addition to literally listing the characters, you may also use ranges of characters (delimited by a '-' Hexadecimal characters started with a '\x'(i.e. \x20) Octal characters started with a '\0' (i.e. \040) Also '\t','\n' and '\r' are recognized. NOTE: If you want the '-' character it needs to be prefixed with a '\' [Syntax] FILTER(allowed-chars,string) [Arguments] Not available [See Also] Not available -- Thanks, --Warren Selby http://www.selbytech.com -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
On Tue, Feb 16, 2010 at 6:28 PM, meetmecall i...@meetmecall.nl 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,01243567505) results in 01243567505. If the length of the output string is shorter then the input string the call setup should stop because not allowed characters were stripped. With some extra lines TRIM() will do as good as the macro I guess. You can add some lines so someone trying to perform number injection will be connected with an answering machine and be requested to leave name and phone number ;-) Erik One thing FILTER() will allow though is variable length dial strings, which are needed in some parts of the world (as evidenced by earlier posts in this thread). -- Thanks, --Warren Selby http://www.selbytech.com -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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-from-voip-old]
exten = _X., 1, dial(SIP/${EXTEN})
To avoid extensive rewriting and fix the current issue.
l.
2010/2/14 Steve Edwards asterisk@sedwards.com
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:]
-
--
Loway - home of QueueMetrics - http://queuemetrics.com
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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 = XX,1,Dial(${ext...@incoming-from-voip-old)
[incoming-from-voip-old]
exten = _X., 1, dial(SIP/${EXTEN})
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 your problems.
Thanks for your suggestion!
/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
Re: [asterisk-users] Important security alert: update your dialplans now!
On Mon, Feb 15, 2010 at 9:51 AM, Olle E. Johansson o...@edvina.net 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 your problems. Thanks for your suggestion! 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? /r -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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 get from Digium on most of these issues is you can already do this in dialplan, therefore we don't need to invest any effort in it. The fact that a workaround may be quite difficult to implement properly doesn't come in to it. The most obvious example of this one is the deprecation and removal of chan_agent without any sort of replacement being introduced because it's already possible to do in the dialplan. -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
15 feb 2010 kl. 10.00 skrev Randy R: On Mon, Feb 15, 2010 at 9:51 AM, Olle E. Johansson o...@edvina.net 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 your problems. Thanks for your suggestion! 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? It's not a stupid question. Many people, including me, has suggested changes and addtions on the -dev list. One thing we can not do, is to change the default behaviour, since that would break as many installations as we help. My suggestion was to change the behaviour of the dot in a pattern match with a switch in the general section of extensions.conf. If you know that you're always ONLY handling pstn phone numbers, that's an easy way to fix the issue. For those that also want to support alphanumeric extensions for VoIP, I suggested a new pattern match that only matched characters allowed in E.164 phone numbers. Remember that there's no magic bullet here, regardless of what happens everyone needs to audit and change their dialplans. We can only make it easier with the addition of new code, but there still is a need of a dialplan audit. /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
Re: [asterisk-users] Important security alert: update your?dialplans now!
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 the dialplan comp?ler to ignore dangerous characters? Whilst I agree with this, the unfortunate attitude we seem to get from Digium on most of these issues is you can already do this in dialplan, therefore we don't need to invest any effort in it. The fact that a workaround may be quite difficult to implement properly doesn't come in to it. The most obvious example of this one is the deprecation and removal of chan_agent without any sort of replacement being introduced because it's already possible to do in the dialplan. Uh, chan_agent has been neither removed nor deprecated. He probably means AgentCallbackLogin -- Michiel van Baak mich...@vanbaak.eu http://michiel.vanbaak.eu GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x71C946BD Why is it drug addicts and computer aficionados are both called users? -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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, you could add a catchall mail the sysadmin option - so when you get a number that is not being matched you could be notified and adjust the dialplan as needed. l. 2010/2/15 Olle E. Johansson o...@edvina.net 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 your problems. Thanks for your suggestion! /O -- Loway - home of QueueMetrics - http://queuemetrics.com -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
On Mon, Feb 15, 2010 at 8:25 AM, Lenz Emilitri lenz.lo...@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(${ext...@incoming-from-voip-old)
instead of :
[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)
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.
murf
BTW, you could add a catchall mail the sysadmin option - so when you get
a number that is not being matched you could be notified and adjust the
dialplan as needed.
l.
2010/2/15 Olle E. Johansson o...@edvina.net
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 your problems.
Thanks for your suggestion!
/O
--
Loway - home of QueueMetrics - http://queuemetrics.com
--
_
-- 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
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
In article 699ee941002150033t7c6e1be5xdba76cb0f68d5...@mail.gmail.com,
Lenz Emilitri lenz.lo...@gmail.com 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-old)
exten = X,1,Dial(${ext...@incoming-from-voip-old)
exten = XX,1,Dial(${ext...@incoming-from-voip-old)
[incoming-from-voip-old]
exten = _X., 1, dial(SIP/${EXTEN})
To avoid extensive rewriting and fix the current issue.
l.
Don't forget you still need the underscore to make X magic:
exten = _XXX,1,Dial(${ext...@incoming-from-voip-old)
etc.
Tony
--
Tony Mountifield
Work: t...@softins.co.uk - http://www.softins.co.uk
Play: t...@mountifield.org - http://tony.mountifield.org
--
_
-- 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
Re: [asterisk-users] Important security alert: update your?dialplans now!
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 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 get from Digium on most of these issues is you can already do this in dialplan, therefore we don't need to invest any effort in it. The fact that a workaround may be quite difficult to implement properly doesn't come in to it. The most obvious example of this one is the deprecation and removal of chan_agent without any sort of replacement being introduced because it's already possible to do in the dialplan. Uh, chan_agent has been neither removed nor deprecated. 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. -- Tilghman Lesher Digium, Inc. | Senior Software Developer twitter: Corydon76 | IRC: Corydon76-dig (Freenode) Check us out at: www.digium.com www.asterisk.org -- _ -- 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
Re: [asterisk-users] Important security alert: update your?dialplans now!
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? -- _ -- 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
Re: [asterisk-users] Important security alert: update your?dialplans now!
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() removed in 1.6.1? I didn't think we did, but apparently so. -- Tilghman Lesher Digium, Inc. | Senior Software Developer twitter: Corydon76 | IRC: Corydon76-dig (Freenode) Check us out at: www.digium.com www.asterisk.org -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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 extensions using
patterns the exception being international calls, but those are in
contexts accessible only from an inside - therefore authenticated -
SIP client.
While I understand you, I don't want to recommend any policy saying that the
inside are allowed to do anything. Experience in network security tells us
that many problems start on the inside. You simply can't divide issues like
this between inside and outside when working with security.
In my opinion there is really no reason why a catch all exten should
be used for unauthenticated clients.
Neither should it be used in any default contexts like [default]. If
one declares all fixed lengths extens and doesn't expose any non fixed
length ones then s/he is safe.
Well, it's not that easy. In Sweden we have variable length phone numbers, as
do many international dial plans. If you want to allow calling to these PSTN
destinations, you will need pattern matching. Which makes you also want to use
filters.
Allowing calling to Internet-based SIP uri's is a different story, but you can
easily handle those too.
However your article is very
informative about how to filter them.
The fix for this - at least at the moment - is education. I doubt it
will take too long to see script kiddies exploiting this.
I can not agree more!
Thank you for the feedback.
Regards,
/Olle
On Sat, Feb 13, 2010 at 6:04 PM, Olle E. Johansson o...@edvina.net wrote:
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-from-voip]
exten = _X., 1, dial(SIP/${EXTEN})
Many VoIP protocols support a large character set, that may cause harm in
your dialplan
I've written an article about this on my blog, where my summary says:
Because of a conflict between allowed characters in the called number or
name in many VoIP protocols and the way Asterisk handles channel variables,
there is a security risk hidden in many dialplans based on examples provided
over the years by the Asterisk developers, trainers and community. The
primary risk is that by using an ampersand in the dialstring, a user can
access protected resources or misuse the pbx services. However, this
character is not the only problem, as other characters may cause unexpected
or problematic behaviour.
There will be an Asterisk Security Advisory document coming out from Digium
soon, as well as updated documentation and examples within the Asterisk
source code tree. I strongly advise everyone to follow these and stay
updated. (I have no access to the ASA system myself and can't generate an
official security alert).
For more information about this issue and some code examples of what I
personally currently think are good ways to prevent misuse of your services,
please read my blog article at
http://www.voip-forum.com/?p=241preview=true
Please help us to distribute this message!
=
We need help from all involved in the Asterisk eco-system. This is not
something that the development team can solve by itself. We can add
documents, READMEs and fix our own examples. But that won’t fix it. We need
everyone involved to pump this information out in all the veins that runs
through the Asterisk eco-system. In all languages needed, we shall say:
Audit your dialplans, fix this issue. And do it now.
Everyone that runs a web site with dialplan examples - audit your examples,
fix them. Everyone that has published books on Asterisk - publish errata on
your web site. Please help us - and do it now.
If you add web links, please add links both to http://www.asterisk.org where
the official documents will soon be published, as well as to my blog (if you
like, of course). But don't just refer to my blog entry alone.
I have updated my own servers and will now start auditing my customers'
servers. After that I will have to update all my training materials so I
don't repeat the bad examples. There's no magic bullet, no wonderful code
patch, that can fix this, just hard work with all dialplans that accept
calls over VoIP channels.
Let us all work together to fix this!
With Asterisk greetings!
/Olle
PS. If someone can update the entries on Queue() and Dial() in
voip-info.org, that would be considered a good thing (TM).
--
_
-- Bandwidth
Re: [asterisk-users] Important security alert: update your dialplans now!
On Sun, Feb 14, 2010 at 2:30 AM, Tzafrir Cohen tzafrir.co...@xorcom.com 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 accessible unauthenticated, I always declare all fixed length extensions using patterns the exception being international calls, but those are in contexts accessible only from an inside - therefore authenticated - SIP client. Still, this allows them to use numbers such as 123456Local/reb...@admin-context . Agreed, but that would mean they would have to guess way too much. Not useful for much. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- _ -- 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 -- _ -- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
On Sun, Feb 14, 2010 at 3:26 AM, Olle E. Johansson o...@edvina.net 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 accessible
unauthenticated, I always declare all fixed length extensions using
patterns the exception being international calls, but those are in
contexts accessible only from an inside - therefore authenticated -
SIP client.
While I understand you, I don't want to recommend any policy saying that the
inside are allowed to do anything. Experience in network security tells us
that many problems start on the inside. You simply can't divide issues like
this between inside and outside when working with security.
Agreed. Using your filtering technique we would accomplish alot more.
In my opinion there is really no reason why a catch all exten should
be used for unauthenticated clients.
Neither should it be used in any default contexts like [default]. If
one declares all fixed lengths extens and doesn't expose any non fixed
length ones then s/he is safe.
Well, it's not that easy. In Sweden we have variable length phone numbers, as
do many international dial plans. If you want to allow calling to these PSTN
destinations, you will need pattern matching. Which makes you also want to
use filters.
Why cant there be 2 or 3 declared fixed length extensions? like
_XX for 10 digit length and _XXX for 11 digit and so
on. The point is there shouldn't be any _X. or _. .
Anyhow, as pointed out by others, while fixed length will allow to
filter out long extensions it will not filter out short ones, which
even though in my opinion practically fixes the problem. The real
solution is only to actually filter out ${EXTEN}.
Allowing calling to Internet-based SIP uri's is a different story, but you
can easily handle those too.
However your article is very
informative about how to filter them.
The fix for this - at least at the moment - is education. I doubt it
will take too long to see script kiddies exploiting this.
I can not agree more!
Thank you for the feedback.
Regards,
/Olle
On Sat, Feb 13, 2010 at 6:04 PM, Olle E. Johansson o...@edvina.net wrote:
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-from-voip]
exten = _X., 1, dial(SIP/${EXTEN})
Many VoIP protocols support a large character set, that may cause harm in
your dialplan
I've written an article about this on my blog, where my summary says:
Because of a conflict between allowed characters in the called number or
name in many VoIP protocols and the way Asterisk handles channel variables,
there is a security risk hidden in many dialplans based on examples
provided over the years by the Asterisk developers, trainers and community.
The primary risk is that by using an ampersand in the dialstring, a user
can access protected resources or misuse the pbx services. However, this
character is not the only problem, as other characters may cause unexpected
or problematic behaviour.
There will be an Asterisk Security Advisory document coming out from Digium
soon, as well as updated documentation and examples within the Asterisk
source code tree. I strongly advise everyone to follow these and stay
updated. (I have no access to the ASA system myself and can't generate an
official security alert).
For more information about this issue and some code examples of what I
personally currently think are good ways to prevent misuse of your
services, please read my blog article at
http://www.voip-forum.com/?p=241preview=true
Please help us to distribute this message!
=
We need help from all involved in the Asterisk eco-system. This is not
something that the development team can solve by itself. We can add
documents, READMEs and fix our own examples. But that won’t fix it. We need
everyone involved to pump this information out in all the veins that runs
through the Asterisk eco-system. In all languages needed, we shall say:
Audit your dialplans, fix this issue. And do it now.
Everyone that runs a web site with dialplan examples - audit your examples,
fix them. Everyone that has published books on Asterisk - publish errata on
your web site. Please help us - and do it now.
If you add web links, please add links both to http://www.asterisk.org
where the official documents will soon be published, as well as to my blog
(if you like, of course). But don't just refer to my blog entry alone.
I have updated my own servers and
Re: [asterisk-users] Important security alert: update your dialplans now!
strip_ampersands(${EXTEN})?
On Sun, Feb 14, 2010 at 10:56 AM, C F shma...@gmail.com wrote:
On Sun, Feb 14, 2010 at 3:26 AM, Olle E. Johansson o...@edvina.net 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 accessible
unauthenticated, I always declare all fixed length extensions using
patterns the exception being international calls, but those are in
contexts accessible only from an inside - therefore authenticated -
SIP client.
While I understand you, I don't want to recommend any policy saying that
the inside are allowed to do anything. Experience in network security
tells us that many problems start on the inside. You simply can't divide
issues like this between inside and outside when working with security.
Agreed. Using your filtering technique we would accomplish alot more.
In my opinion there is really no reason why a catch all exten should
be used for unauthenticated clients.
Neither should it be used in any default contexts like [default]. If
one declares all fixed lengths extens and doesn't expose any non fixed
length ones then s/he is safe.
Well, it's not that easy. In Sweden we have variable length phone numbers,
as do many international dial plans. If you want to allow calling to these
PSTN destinations, you will need pattern matching. Which makes you also want
to use filters.
Why cant there be 2 or 3 declared fixed length extensions? like
_XX for 10 digit length and _XXX for 11 digit and so
on. The point is there shouldn't be any _X. or _. .
Anyhow, as pointed out by others, while fixed length will allow to
filter out long extensions it will not filter out short ones, which
even though in my opinion practically fixes the problem. The real
solution is only to actually filter out ${EXTEN}.
Allowing calling to Internet-based SIP uri's is a different story, but you
can easily handle those too.
However your article is very
informative about how to filter them.
The fix for this - at least at the moment - is education. I doubt it
will take too long to see script kiddies exploiting this.
I can not agree more!
Thank you for the feedback.
Regards,
/Olle
On Sat, Feb 13, 2010 at 6:04 PM, Olle E. Johansson o...@edvina.net wrote:
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-from-voip]
exten = _X., 1, dial(SIP/${EXTEN})
Many VoIP protocols support a large character set, that may cause harm in
your dialplan
I've written an article about this on my blog, where my summary says:
Because of a conflict between allowed characters in the called number or
name in many VoIP protocols and the way Asterisk handles channel
variables, there is a security risk hidden in many dialplans based on
examples provided over the years by the Asterisk developers, trainers and
community. The primary risk is that by using an ampersand in the
dialstring, a user can access protected resources or misuse the pbx
services. However, this character is not the only problem, as other
characters may cause unexpected or problematic behaviour.
There will be an Asterisk Security Advisory document coming out from
Digium soon, as well as updated documentation and examples within the
Asterisk source code tree. I strongly advise everyone to follow these and
stay updated. (I have no access to the ASA system myself and can't
generate an official security alert).
For more information about this issue and some code examples of what I
personally currently think are good ways to prevent misuse of your
services, please read my blog article at
http://www.voip-forum.com/?p=241preview=true
Please help us to distribute this message!
=
We need help from all involved in the Asterisk eco-system. This is not
something that the development team can solve by itself. We can add
documents, READMEs and fix our own examples. But that won’t fix it. We
need everyone involved to pump this information out in all the veins that
runs through the Asterisk eco-system. In all languages needed, we shall
say: Audit your dialplans, fix this issue. And do it now.
Everyone that runs a web site with dialplan examples - audit your
examples, fix them. Everyone that has published books on Asterisk -
publish errata on your web site. Please help us - and do it now.
If you add web links, please add links both to http://www.asterisk.org
where the official documents will soon be published, as well as to my blog
(if you
Re: [asterisk-users] Important security alert: update your dialplans now!
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,
-
Steve Edwards sedwa...@sedwards.com Voice: +1-760-468-3867 PST
Newline Fax: +1-760-731-3000
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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
asterisk@sedwards.com wrote:
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,
-
Steve Edwards sedwa...@sedwards.com Voice: +1-760-468-3867 PST
Newline Fax: +1-760-731-3000
--
_
-- 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
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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= [:numeric:]
The ampersand is not the only dangerous character and it's not only about the
SIP channel, but I do understand what you mean. I wonder if this would give
users a sense of false security, as you always have to be careful in your
dialplan...
We could easily implement a function that checks if the current extension is a
valid E.164 phone number, but that's more or less the same as what you can do
with REGEX, CUT and FILTER in various combinations today, just more simple for
the admin. We already have that functionality in the internal API.
I posted another solution to the -dev list, where I suggested that we
implemented a variable in the general section of extensions.conf to change the
behaviour of the dot in pattern matches. That would be a simple way to help
admins fix the issue. In my suggestion was also an idea of a double-dot that
would only match E.164 approved characters and dot would keep the current
functionality, so we could have Asterisk installations with full VoIP support
without PSTN filters.
/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
Re: [asterisk-users] Important security alert: update your dialplans now!
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:tzafrir.co...@xorcom.com
http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir
--
_
-- 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
[asterisk-users] Important security alert: update your dialplans now!
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-from-voip]
exten = _X., 1, dial(SIP/${EXTEN})
Many VoIP protocols support a large character set, that may cause harm in your
dialplan
I've written an article about this on my blog, where my summary says:
Because of a conflict between allowed characters in the called number or name
in many VoIP protocols and the way Asterisk handles channel variables, there is
a security risk hidden in many dialplans based on examples provided over the
years by the Asterisk developers, trainers and community. The primary risk is
that by using an ampersand in the dialstring, a user can access protected
resources or misuse the pbx services. However, this character is not the only
problem, as other characters may cause unexpected or problematic behaviour.
There will be an Asterisk Security Advisory document coming out from Digium
soon, as well as updated documentation and examples within the Asterisk source
code tree. I strongly advise everyone to follow these and stay updated. (I have
no access to the ASA system myself and can't generate an official security
alert).
For more information about this issue and some code examples of what I
personally currently think are good ways to prevent misuse of your services,
please read my blog article at
http://www.voip-forum.com/?p=241preview=true
Please help us to distribute this message!
=
We need help from all involved in the Asterisk eco-system. This is not
something that the development team can solve by itself. We can add documents,
READMEs and fix our own examples. But that won’t fix it. We need everyone
involved to pump this information out in all the veins that runs through the
Asterisk eco-system. In all languages needed, we shall say: Audit your
dialplans, fix this issue. And do it now.
Everyone that runs a web site with dialplan examples - audit your examples, fix
them. Everyone that has published books on Asterisk - publish errata on your
web site. Please help us - and do it now.
If you add web links, please add links both to http://www.asterisk.org where
the official documents will soon be published, as well as to my blog (if you
like, of course). But don't just refer to my blog entry alone.
I have updated my own servers and will now start auditing my customers'
servers. After that I will have to update all my training materials so I don't
repeat the bad examples. There's no magic bullet, no wonderful code patch, that
can fix this, just hard work with all dialplans that accept calls over VoIP
channels.
Let us all work together to fix this!
With Asterisk greetings!
/Olle
PS. If someone can update the entries on Queue() and Dial() in voip-info.org,
that would be considered a good thing (TM).
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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, but those are in
contexts accessible only from an inside - therefore authenticated -
SIP client.
In my opinion there is really no reason why a catch all exten should
be used for unauthenticated clients.
Neither should it be used in any default contexts like [default]. If
one declares all fixed lengths extens and doesn't expose any non fixed
length ones then s/he is safe. However your article is very
informative about how to filter them.
The fix for this - at least at the moment - is education. I doubt it
will take too long to see script kiddies exploiting this.
On Sat, Feb 13, 2010 at 6:04 PM, Olle E. Johansson o...@edvina.net wrote:
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-from-voip]
exten = _X., 1, dial(SIP/${EXTEN})
Many VoIP protocols support a large character set, that may cause harm in
your dialplan
I've written an article about this on my blog, where my summary says:
Because of a conflict between allowed characters in the called number or
name in many VoIP protocols and the way Asterisk handles channel variables,
there is a security risk hidden in many dialplans based on examples provided
over the years by the Asterisk developers, trainers and community. The
primary risk is that by using an ampersand in the dialstring, a user can
access protected resources or misuse the pbx services. However, this
character is not the only problem, as other characters may cause unexpected
or problematic behaviour.
There will be an Asterisk Security Advisory document coming out from Digium
soon, as well as updated documentation and examples within the Asterisk
source code tree. I strongly advise everyone to follow these and stay
updated. (I have no access to the ASA system myself and can't generate an
official security alert).
For more information about this issue and some code examples of what I
personally currently think are good ways to prevent misuse of your services,
please read my blog article at
http://www.voip-forum.com/?p=241preview=true
Please help us to distribute this message!
=
We need help from all involved in the Asterisk eco-system. This is not
something that the development team can solve by itself. We can add
documents, READMEs and fix our own examples. But that won’t fix it. We need
everyone involved to pump this information out in all the veins that runs
through the Asterisk eco-system. In all languages needed, we shall say:
Audit your dialplans, fix this issue. And do it now.
Everyone that runs a web site with dialplan examples - audit your examples,
fix them. Everyone that has published books on Asterisk - publish errata on
your web site. Please help us - and do it now.
If you add web links, please add links both to http://www.asterisk.org where
the official documents will soon be published, as well as to my blog (if you
like, of course). But don't just refer to my blog entry alone.
I have updated my own servers and will now start auditing my customers'
servers. After that I will have to update all my training materials so I
don't repeat the bad examples. There's no magic bullet, no wonderful code
patch, that can fix this, just hard work with all dialplans that accept calls
over VoIP channels.
Let us all work together to fix this!
With Asterisk greetings!
/Olle
PS. If someone can update the entries on Queue() and Dial() in voip-info.org,
that would be considered a good thing (TM).
--
_
-- 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
--
_
-- 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
Re: [asterisk-users] Important security alert: update your dialplans now!
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 extensions using patterns the exception being international calls, but those are in contexts accessible only from an inside - therefore authenticated - SIP client. Still, this allows them to use numbers such as 123456Local/reb...@admin-context . -- Tzafrir Cohen icq#16849755 jabber:tzafrir.co...@xorcom.com +972-50-7952406 mailto:tzafrir.co...@xorcom.com http://www.xorcom.com iax:gu...@local.xorcom.com/tzafrir -- _ -- 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
