Compare commits

..

3 Commits

Author SHA1 Message Date
Leif Madsen
7afb12e0d2 Importing release summary for 1.2.39 release.
git-svn-id: https://origsvn.digium.com/svn/asterisk/tags/1.2.39@246121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-02-10 17:53:53 +00:00
Leif Madsen
808e14dfb7 Importing files for 1.2.39 release.
git-svn-id: https://origsvn.digium.com/svn/asterisk/tags/1.2.39@246120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-02-10 17:53:49 +00:00
Leif Madsen
23ebe2e7fb Creating tag for the release of asterisk-1.2.39
git-svn-id: https://origsvn.digium.com/svn/asterisk/tags/1.2.39@246118 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-02-10 17:52:45 +00:00
6 changed files with 25 additions and 378 deletions

View File

@@ -1 +1 @@
1.2.40
1.2.39

View File

@@ -1,23 +1,3 @@
2010-02-18 Leif Madsen <lmadsen@digium.com>
* Asterisk 1.2.40 released
2010-02-18 16:53 +0000 [r247501-247507] Leif Madsen <lmadsen@digium.com>
* README-SERIOUSLY.bestpractices.txt: Add additional link to best
practices document per jsmith.
* README-SERIOUSLY.bestpractices.txt (added): Add best practices
documentation. (closes issue #16808) Reported by: lmadsen (closes
issue #16810) Reported by: Nick_Lewis Tested by: lmadsen Review:
https://reviewboard.asterisk.org/r/507/
2010-02-17 00:09 +0000 [r247081] Tilghman Lesher <tlesher@digium.com>
* funcs/func_strings.c: AST-2010-002: Backport FILTER() function to
1.2, as it needed for the suggested solution. Review:
http://reviewboard.digium.internal/r/31/
2010-02-10 Leif Madsen <lmadsen@digium.com>
* Asterisk 1.2.39 released

View File

@@ -1,295 +0,0 @@
==================
| Best Practices |
==================
The purpose of this document is to define best practices when working with
Asterisk in order to minimize possible security breaches and to provide tried
examples in field deployments. This is a living document and is subject to
change over time as best practices are defined.
--------
Sections
--------
* Filtering Data:
How to protect yourself from redial attacks
* Proper Device Naming:
Why to not use numbered extensions for devices
* Secure Passwords:
Secure passwords limit your risk to brute force attacks
* Reducing Pattern Match Typos:
Using the 'same' prefix, or using Goto()
----------------
Additional Links
----------------
Additional links that contain useful information about best practices or
security are listed below.
* Seven Steps to Better SIP Security:
http://blogs.digium.com/2009/03/28/sip-security/
* Asterisk VoIP Security (webinar):
http://www.asterisk.org/security/webinar/
==============
Filtering Data
==============
In the Asterisk dialplan, several channel variables contain data potentially
supplied by outside sources. This could lead to a potential security concern
where those outside sources may send cleverly crafted strings of data which
could be utilized, e.g. to place calls to unexpected locations.
An example of this can be found in the use of pattern matching and the ${EXTEN}
channel variable. Note that ${EXTEN} is not the only system created channel
variable, so it is important to be aware of where the data you're using is
coming from.
For example, this common dialplan takes 2 or more characters of data, starting
with a number 0-9, and then accepts any additional information supplied by the
request.
[NOTE: We use SIP in this example, but is not limited to SIP only; protocols
such as Jabber/XMPP or IAX2 are also susceptible to the same sort of
injection problem.]
[incoming]
exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN})
exten => _X.,n,Dial(SIP/${EXTEN})
exten => _X.,n,Hangup()
This dialplan may be utilized to accept calls to extensions, which then dial a
numbered device name configured in one of the channel configuration files (such
as sip.conf, iax.conf, etc...) (see the section Proper Device Naming for more
information on why this approach is flawed).
The example we've given above looks harmless enough until you take into
consideration that several channel technologies accept characters that could
be utilized in a clever attack. For example, instead of just sending a request
to dial extension 500 (which in our example above would create the string
SIP/500 and is then used by the Dial() application to place a call), someone
could potentially send a string like "500&SIP/itsp/14165551212".
The string "500&SIP/itsp/14165551212" would then be contained within the
${EXTEN} channel variable, which is then utilized by the Dial() application in
our example, thereby giving you the dialplan line of:
exten => _X.,n,Dial(SIP/500&SIP/itsp/14165551212)
Our example above has now provided someone with a method to place calls out of
your ITSP in a place where you didn't expect to allow it. There are a couple of
ways in which you can mitigate this impact: stricter pattern matching, or using
the FILTER() dialplan function.
Strict Pattern Matching
-----------------------
The simple way to mitigate this problem is with a strict pattern match that does
not utilize the period (.) or bang (!) characters to match on one-or-more
characters or zero-or-more characters (respectively). To fine tune our example
to only accept three digit extensions, we could change our pattern match to
be:
exten => _XXX,n,Dial(SIP/${EXTEN})
In this way, we have minimized our impact because we're not allowing anything
other than the numbers zero through nine. But in some cases we really do need to
handle variable pattern matches, such as when dialing international numbers
or when we want to handle something like a SIP URI. In this case, we'll need to
utilize the FILTER() dialplan function.
Using FILTER()
--------------
The FILTER() dialplan function is used to filter strings by only allowing
characters that you have specified. This is a perfect candidate for controlling
which characters you want to pass to the Dial() application, or any other
application which will contain dynamic information passed to Asterisk from an
external source. Lets take a look at how we can use FILTER() to control what
data we allow.
Using our previous example to accept any string length of 2 or more characters,
starting with a number of zero through nine, we can use FILTER() to limit what
we will accept to just numbers. Our example would then change to something like:
[incoming]
exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN})
exten => _X.,n,Dial(SIP/${FILTER(0-9,${EXTEN})})
exten => _X.,n,Hangup()
Note how we've wrapped the ${EXTEN} channel variable with the FILTER() function
which will then only pass back characters that fit into the numerical range that
we've defined.
Alternatively, if we didn't want to utilize the FILTER() function within the
Dial() application directly, we could save the value to a channel variable,
which has a side effect of being usable in other locations of your dialplan if
necessary, and to handle error checking in a separate location.
[incoming]
exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN})
exten => _X.,n,Set(SAFE_EXTEN=${FILTER(0-9,${EXTEN})})
exten => _X.,n,Dial(SIP/${SAFE_EXTEN})
exten => _X.,n,Hangup()
Now we can use the ${SAFE_EXTEN} channel variable anywhere throughout the rest
of our dialplan, knowing we've already filtered it. We could also perform an
error check to verify that what we've received in ${EXTEN} also matches the data
passed back by FILTER(), and to fail the call if things do not match.
[incoming]
exten => _X.,1,Verbose(2,Incoming call to extension ${EXTEN})
exten => _X.,n,Set(SAFE_EXTEN=${FILTER(0-9,${EXTEN})})
exten => _X.,n,GotoIf($[${EXTEN} != ${SAFE_EXTEN}]?error,1)
exten => _X.,n,Dial(SIP/${SAFE_EXTEN})
exten => _X.,n,Hangup()
exten => error,1,Verbose(2,Values of EXTEN and SAFE_EXTEN did not match.)
exten => error,n,Verbose(2,EXTEN: "${EXTEN}" -- SAFE_EXTEN: "${SAFE_EXTEN}")
exten => error,n,Playback(silence/1&invalid)
exten => error,n,Hangup()
Another example would be using FILTER() to control the characters we accept when
we're expecting to get a SIP URI for dialing.
[incoming]
exten => _[0-9a-zA-Z].,1,Verbose(2,Incoming call to extension ${EXTEN})
exten => _[0-9a-zA-Z].,n,Dial(SIP/${FILTER(.@0-9a-zA-Z,${EXTEN})
exten => _[0-9a-zA-Z].,n,Hangup()
Of course the FILTER() function doesn't check the formatting of the incoming
request. There is also the REGEX() dialplan function which can be used to
determine if the string passed to it matches the regular expression you've
created, and to take proper action on whether it matches or not. The creation of
regular expressions is left as an exercise for the reader.
More information about the FILTER() and REGEX() dialplan functions can be found
by typing "core show function FILTER" and "core show function REGEX" from your
Asterisk console.
====================
Proper Device Naming
====================
In Asterisk, the concept of an extension number being tied to a specific device
does not exist. Asterisk is aware of devices it can call or receive calls from,
and how you define in your dialplan how to reach those devices is up to you.
Because it has become common practice to think of a specific device as having an
extension number associated with it, it only becomes natural to think about
naming your devices the same as the extension number you're providing it. But
by doing this, you're limiting the powerful concept of separating user from
extensions, and extensions from devices.
It can also be a security hazard to name your devices with a number, as this can
open you up to brute force attacks. Many of the current exploits deal with
device configurations which utilize a number, and even worse, a password that
matches the devices name. For example, take a look at this poorly created device
in sip.conf:
[1000]
type=friend
context=international_dialing
secret=1000
As implied by the context, we've permitted a device named 1000 with a password
of 1000 to place calls internationally. If your PBX system is accessible via
the internet, then your system will be vulnerable to expensive international
calls. Even if your system is not accessible via the internet, people within
your organization could get access to dialing rules you'd prefer to reserve only
for certain people.
A more secure example for the device would be to use something like the MAC
address of the device, along with a strong password (see the section Secure
Passwords). The following example would be more secure:
[0004f2040001]
type=friend
context=international_dialing
secret=aE3%B8*$jk^G
Then in your dialplan, you would reference the device via the MAC address of the
device (or if using the softphone, a MAC address of a network interface on the
computer).
Also note that you should NOT use this password, as it will likely be one of the
first ones added to the dictionary for brute force attacks.
================
Secure Passwords
================
Secure passwords are necessary in many (if not all) environments, and Asterisk
is certainly no exception, especially when it comes to expensive long distance
calls that could potentially cost your company hundreds or thousands of dollars
on an expensive monthly phone bill, with little to no recourse to fight the
charges.
Whenever you are positioned to add a password to your system, whether that is
for a device configuration, a database connection, or any other secure
connection, be sure to use a secure password. A good example of a secure
password would be something like:
aE3%B8*$jk^G
Our password also contains 12 characters with a mixture of upper and
lower case characters, numbers, and symbols. Because these passwords are likely
to only be entered once, or loaded via a configuration file, there is
no need to create simple passwords, even in testing. Some of the holes found in
production systems used for exploitations involve finding the one test extension
that contains a weak password that was forgotten prior to putting a system into
production.
Using a web search you can find several online password generators such as
http://www.strongpasswordgenerator.com or there are several scripts that can be
used to generate a strong password.
============================
Reducing Pattern Match Typos
============================
As of Asterisk 1.6.2, a new method for reducing the number of complex pattern
matches you need to enter, which can reduce typos in your dialplan, has been
implemented. Traditionally, a dialplan with a complex pattern match would look
something like:
exten => _[3-5]XXX,1,Verbose(Incoming call to ${EXTEN})
exten => _[3-5]XXX,n,Set(DEVICE=${DB(device/mac_address/${EXTEN})})
exten => _[3-5]XXX,n,Set(TECHNOLOGY=${DB(device/technology/${EXTEN})})
exten => _[3-5]XXX,n,GotoIf($[${ISNULL(${TECHNOLOGY})} | ${ISNULL(${DEVICE})}]?error,1)
exten => _[3-5]XXX,n,Dial(${TECHNOLOGY}/${DEVICE},${GLOBAL(TIMEOUT)})
exten => _[3-5]XXX,n,Set(vmFlag=${IF($[${DIALSTATUS} = BUSY]?b:u)})
exten => _[3-5]XXX,n,Voicemail(${EXTEN}@${GLOBAL(VOICEMAIL_CONTEXT)},${vmFlag})
exten => _[3-5]XXX,n,Hangup()
exten => error,1,Verbose(2,Unable to lookup technology or device for extension)
exten => error,n,Playback(silence/1&num-not-in-db)
exten => error,n,Hangup()
Of course there exists the possibility for a typo when retyping the pattern
match _[3-5]XXX which will match on extensions 3000 through 5999. We can
minimize this error by utilizing the same => prefix on all lines beyond the
first one. Our same dialplan with using same => would look like the following:
exten => _[3-5]XXX,1,Verbose(Incoming call to ${EXTEN})
same => n,Set(DEVICE=${DB(device/mac_address/${EXTEN})})
same => n,Set(TECHNOLOGY=${DB(device/technology/${EXTEN})})
same => n,GotoIf($[${ISNULL(${TECHNOLOGY})} | ${ISNULL(${DEVICE})}]?error,1)
same => n,Dial(${TECHNOLOGY}/${DEVICE},${GLOBAL(TIMEOUT)})
same => n,Set(vmFlag=${IF($[${DIALSTATUS} = BUSY]?b:u)})
same => n,Voicemail(${EXTEN}@${GLOBAL(VOICEMAIL_CONTEXT)},${vmFlag})
same => n,Hangup()
exten => error,1,Verbose(2,Unable to lookup technology or device for extension)
same => n,Playback(silence/1&num-not-in-db)
same => n,Hangup()

View File

@@ -1,10 +1,10 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /><title>Release Summary - asterisk-1.2.40</title></head>
<head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /><title>Release Summary - asterisk-1.2.39</title></head>
<body>
<h1 align="center"><a name="top">Release Summary</a></h1>
<h3 align="center">asterisk-1.2.40</h3>
<h3 align="center">Date: 2010-02-18</h3>
<h3 align="center">asterisk-1.2.39</h3>
<h3 align="center">Date: 2010-02-10</h3>
<h3 align="center">&lt;asteriskteam@digium.com&gt;</h3>
<hr/>
<h2 align="center">Table of Contents</h2>
@@ -16,9 +16,8 @@
</ol>
<hr/>
<a name="summary"><h2 align="center">Summary</h2></a>
<center><a href="#top">[Back to Top]</a></center><br/><p>This release has been made to address one or more security vulnerabilities that have been identified. A security advisory document has been published for each vulnerability that includes additional information. Users of versions of Asterisk that are affected are strongly encouraged to review the advisories and determine what action they should take to protect their systems from these issues.</p>
<p>Security Advisories: <a href="http://downloads.asterisk.org/pub/security/AST-2010-002.html">AST-2010-002</a></p>
<p>The data in this summary reflects changes that have been made since the previous release, asterisk-1.2.39.</p>
<center><a href="#top">[Back to Top]</a></center><br/><p>This release includes only bug fixes. The changes included were made only to address problems that have been identified in this release series. Users should be able to safely upgrade to this version if this release series is already in use. Users considering upgrading from a previous release series are strongly encouraged to review the UPGRADE.txt document as well as the CHANGES document for information about upgrading to this release series.</p>
<p>The data in this summary reflects changes that have been made since the previous release, asterisk-1.2.38.</p>
<hr/>
<a name="contributors"><h2 align="center">Contributors</h2></a>
<center><a href="#top">[Back to Top]</a></center><br/><p>This table lists the people who have submitted code, those that have tested patches, as well as those that reported issues on the issue tracker that were resolved in this release. For coders, the number is how many of their patches (of any size) were committed into this release. For testers, the number is the number of times their name was listed as assisting with testing a patch. Finally, for reporters, the number is the number of issues that they reported that were closed by commits that went into this release.</p>
@@ -30,7 +29,7 @@
</tr>
<tr valign="top">
<td>
1 lmadsen<br/>
1 dvossel<br/>
</td>
<td>
</td>
@@ -42,13 +41,14 @@
<a name="commits"><h2 align="center">Commits Not Associated with an Issue</h2></a>
<center><a href="#top">[Back to Top]</a></center><br/><p>This is a list of all changes that went into this release that did not directly close an issue from the issue tracker. The commits may have been marked as being related to an issue. If that is the case, the issue numbers are listed here, as well.</p>
<table width="100%" border="1">
<tr><td><b>Revision</b></td><td><b>Author</b></td><td><b>Summary</b></td><td><b>Issues Referenced</b></td></tr><tr><td><a href="http://svn.digium.com/view/asterisk/tags/1.2.40?view=revision&revision=247513">247513</a></td><td>lmadsen</td><td>Creating tag for the release of asterisk-1.2.40</td>
<tr><td><b>Revision</b></td><td><b>Author</b></td><td><b>Summary</b></td><td><b>Issues Referenced</b></td></tr><tr><td><a href="http://svn.digium.com/view/asterisk/branches/1.2?view=revision&revision=245874">245874</a></td><td>dvossel</td><td>fixes regression caused by randomized call numbers.</td>
<td></td></tr></table>
<hr/>
<a name="diffstat"><h2 align="center">Diffstat Results</h2></a>
<center><a href="#top">[Back to Top]</a></center><br/><p>This is a summary of the changes to the source code that went into this release that was generated using the diffstat utility.</p>
<pre>
0 files changed
chan_iax2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
</pre><br/>
<hr/>
</body>

View File

@@ -1,8 +1,8 @@
Release Summary
asterisk-1.2.40
asterisk-1.2.39
Date: 2010-02-18
Date: 2010-02-10
<asteriskteam@digium.com>
@@ -21,17 +21,16 @@
[Back to Top]
This release has been made to address one or more security vulnerabilities
that have been identified. A security advisory document has been published
for each vulnerability that includes additional information. Users of
versions of Asterisk that are affected are strongly encouraged to review
the advisories and determine what action they should take to protect their
systems from these issues.
Security Advisories: AST-2010-002
This release includes only bug fixes. The changes included were made only
to address problems that have been identified in this release series.
Users should be able to safely upgrade to this version if this release
series is already in use. Users considering upgrading from a previous
release series are strongly encouraged to review the UPGRADE.txt document
as well as the CHANGES document for information about upgrading to this
release series.
The data in this summary reflects changes that have been made since the
previous release, asterisk-1.2.39.
previous release, asterisk-1.2.38.
----------------------------------------------------------------------
@@ -49,7 +48,7 @@
release.
Coders Testers Reporters
1 lmadsen
1 dvossel
----------------------------------------------------------------------
@@ -65,8 +64,8 @@
+------------------------------------------------------------------------+
| Revision | Author | Summary | Issues Referenced |
|----------+---------+-------------------------------+-------------------|
| 247513 | lmadsen | Creating tag for the release | |
| | | of asterisk-1.2.40 | |
| 245874 | dvossel | fixes regression caused by | |
| | | randomized call numbers. | |
+------------------------------------------------------------------------+
----------------------------------------------------------------------
@@ -78,6 +77,7 @@
This is a summary of the changes to the source code that went into this
release that was generated using the diffstat utility.
0 files changed
chan_iax2.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
----------------------------------------------------------------------

View File

@@ -77,44 +77,6 @@ struct ast_custom_function fieldqty_function = {
.read = function_fieldqty,
};
static char *filter(struct ast_channel *chan, char *cmd, char *parse, char *buf, size_t len)
{
char *string, *allowed;
char *outbuf = buf;
ast_copy_string(buf, "0", len);
if (!(string = ast_strdupa(parse))) {
return buf;
}
allowed = strsep(&string, "|");
if (!string) {
ast_log(LOG_ERROR, "Usage: FILTER(<allowed-chars>|<string>)\n");
return buf;
}
for (; *string && (buf + len - 1 > outbuf); string++) {
if (strchr(allowed, *string)) {
*outbuf++ = *string;
}
}
*outbuf = '\0';
return buf;
}
#ifndef BUILTIN_FUNC
static
#endif
struct ast_custom_function filter_function = {
.name = "FILTER",
.synopsis = "Filter the string to include only the allowed characters",
.syntax = "FILTER(<allowed-chars>|<string>)",
.read = filter,
};
static char *builtin_function_regex(struct ast_channel *chan, char *cmd, char *data, char *buf, size_t len)
{
char *arg, *earg = NULL, *tmp, errstr[256] = "";