Importing release summary for 1.2.40 release.

git-svn-id: https://origsvn.digium.com/svn/asterisk/tags/1.2.40@247515 65c4cc65-6c06-0410-ace0-fbb531ad65f3

.version

@@ -1 +1 @@
-1.2.36
+1.2.40

ChangeLog

@@ -1,3 +1,53 @@
+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
+
+2010-02-09 23:35 +0000 [r245874]  David Vossel <dvossel@digium.com>
+
+	* channels/chan_iax2.c: fixes regression caused by randomized call
+	  numbers. (closes issue 0015997) Reported by: exarv Patches:
+	  iax_fix.diff uploaded by dvossel (license 671)
+
+2010-02-09  Leif Madsen <lmadsen@digium.com>
+
+	* Asterisk 1.2.38 released
+
+	* Previous regression commits were not properly rolled into
+	  releases. This release re-syncs the commits. 
+
+2009-11-30  Leif Madsen <lmadsen@digium.com>
+
+	* Asterisk 1.2.37 released
+
+	* AST-2009-010
+
+2009-11-30 17:35 +0000 [r231518]  David Vossel <dvossel@digium.com>
+
+	* rtp.c: fixes crash caused by RTP comfort noise payload greater
+	  than 24 bytes AST-2009-010 (closes issue #16242) Reported by:
+	  amorsen Patches: issue16242.diff uploaded by oej (license 306)
+	  Tested by: amorsen, oej, dvossel
+
 2009-11-04  Leif Madsen <lmadsen@digium.com>
 
 	* Asterisk 1.2.36 released

README-SERIOUSLY.bestpractices.txt

@@ -0,0 +1,295 @@
+==================
+| 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()

asterisk-1.2.35-summary.html

@@ -1,86 +0,0 @@
-<!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.35</title></head>
-<body>
-<h1 align="center"><a name="top">Release Summary</a></h1>
-<h3 align="center">asterisk-1.2.35</h3>
-<h3 align="center">Date: 2009-09-03</h3>
-<h3 align="center">&lt;asteriskteam@digium.com&gt;</h3>
-<hr/>
-<h2 align="center">Table of Contents</h2>
-<ol>
-   <li><a href="#summary">Summary</a></li>
-   <li><a href="#contributors">Contributors</a></li>
-   <li><a href="#issues">Closed Issues</a></li>
-   <li><a href="#commits">Other Changes</a></li>
-   <li><a href="#diffstat">Diffstat</a></li>
-</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/.html"></a></p>
-<p>The data in this summary reflects changes that have been made since the previous release, asterisk-1.2.34.</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>
-<table width="100%" border="0">
-<tr>
-<td width="33%"><h3>Coders</h3></td>
-<td width="33%"><h3>Testers</h3></td>
-<td width="33%"><h3>Reporters</h3></td>
-</tr>
-<tr valign="top">
-<td>
-1 dvossel<br/>
-1 russell<br/>
-</td>
-<td>
-1 dbrooks<br/>
-1 dvossel<br/>
-1 russell<br/>
-1 tilghman<br/>
-</td>
-<td>
-1 rathaus<br/>
-</td>
-</tr>
-</table>
-<hr/>
-<a name="issues"><h2 align="center">Closed Issues</h2></a>
-<center><a href="#top">[Back to Top]</a></center><br/><p>This is a list of all issues from the issue tracker that were closed by changes that went into this release.</p>
-<h3>Category: Channels/chan_iax2</h3><br/>
-<a href="https://issues.asterisk.org/view.php?id=12912">#12912</a>: An issue with the IAX2 channel allows anonymous connections to cause resource starvation<br/>
-Revision: <a href="http://svn.digium.com/view/asterisk/tags/1.2.35?view=revision&revision=215958">215958</a><br/>
-Reporter: rathaus<br/>
-Testers: tilghman, russell, dvossel, dbrooks<br/>
-Coders: dvossel<br/>
-<br/>
-<hr/>
-<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.35?view=revision&revision=216005">216005</a></td><td>russell</td><td>Add IAX2 security document related to AST-2009-006.</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>
-Makefile                   |    2
-acl.c                      |   12
-astobj2.c                  |   19
-channels/chan_iax2.c       | 1348 +++++++++++++++++++++++++++++++++++++++++----
-channels/iax2-parser.c     |   11
-channels/iax2-parser.h     |    2
-channels/iax2.h            |    2
-configs/iax.conf.sample    |   56 +
-include/asterisk/acl.h     |   13
-include/asterisk/astobj2.h |   10
-include/asterisk/sha1.h    |   81 ++
-include/asterisk/utils.h   |    4
-sha1.c                     |  385 ++++++++++++
-utils.c                    |   19
-14 files changed, 1829 insertions(+), 135 deletions(-)
-</pre><br/>
-<hr/>
-</body>
-</html>

asterisk-1.2.35-summary.txt

@@ -1,119 +0,0 @@
-                                Release Summary
-
-                                asterisk-1.2.35
-
-                                Date: 2009-09-03
-
-                           <asteriskteam@digium.com>
-
-     ----------------------------------------------------------------------
-
-                               Table of Contents
-
-    1. Summary
-    2. Contributors
-    3. Closed Issues
-    4. Other Changes
-    5. Diffstat
-
-     ----------------------------------------------------------------------
-
-                                    Summary
-
-                                 [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:
-
-   The data in this summary reflects changes that have been made since the
-   previous release, asterisk-1.2.34.
-
-     ----------------------------------------------------------------------
-
-                                  Contributors
-
-                                 [Back to Top]
-
-   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.
-
-     Coders                   Testers                  Reporters              
-   1 dvossel                1 dbrooks                1 rathaus                
-   1 russell                1 dvossel                
-                            1 russell                
-                            1 tilghman               
-
-     ----------------------------------------------------------------------
-
-                                 Closed Issues
-
-                                 [Back to Top]
-
-   This is a list of all issues from the issue tracker that were closed by
-   changes that went into this release.
-
-  Category: Channels/chan_iax2
-
-   #12912: An issue with the IAX2 channel allows anonymous connections to
-   cause resource starvation
-   Revision: 215958
-   Reporter: rathaus
-   Testers: tilghman, russell, dvossel, dbrooks
-   Coders: dvossel
-
-     ----------------------------------------------------------------------
-
-                      Commits Not Associated with an Issue
-
-                                 [Back to Top]
-
-   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.
-
-   +------------------------------------------------------------------------+
-   | Revision | Author  | Summary                       | Issues Referenced |
-   |----------+---------+-------------------------------+-------------------|
-   | 216005   | russell | Add IAX2 security document    |                   |
-   |          |         | related to AST-2009-006.      |                   |
-   +------------------------------------------------------------------------+
-
-     ----------------------------------------------------------------------
-
-                                Diffstat Results
-
-                                 [Back to Top]
-
-   This is a summary of the changes to the source code that went into this
-   release that was generated using the diffstat utility.
-
- Makefile                   |    2
- acl.c                      |   12
- astobj2.c                  |   19
- channels/chan_iax2.c       | 1348 +++++++++++++++++++++++++++++++++++++++++----
- channels/iax2-parser.c     |   11
- channels/iax2-parser.h     |    2
- channels/iax2.h            |    2
- configs/iax.conf.sample    |   56 +
- include/asterisk/acl.h     |   13
- include/asterisk/astobj2.h |   10
- include/asterisk/sha1.h    |   81 ++
- include/asterisk/utils.h   |    4
- sha1.c                     |  385 ++++++++++++
- utils.c                    |   19
- 14 files changed, 1829 insertions(+), 135 deletions(-)
-
-     ----------------------------------------------------------------------

asterisk-1.2.40-summary.html

@@ -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.36</title></head>
+<head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /><title>Release Summary - asterisk-1.2.40</title></head>
 <body>
 <h1 align="center"><a name="top">Release Summary</a></h1>
-<h3 align="center">asterisk-1.2.36</h3>
-<h3 align="center">Date: 2009-11-04</h3>
+<h3 align="center">asterisk-1.2.40</h3>
+<h3 align="center">Date: 2010-02-18</h3>
 <h3 align="center">&lt;asteriskteam@digium.com&gt;</h3>
 <hr/>
 <h2 align="center">Table of Contents</h2>
@@ -17,8 +17,8 @@
 <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-2009-008.html">AST-2009-008</a></p>
-<p>The data in this summary reflects changes that have been made since the previous release, asterisk-1.2.35.</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>
 <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,8 +30,7 @@
 </tr>
 <tr valign="top">
 <td>
-2 lmadsen<br/>
-1 file<br/>
+1 lmadsen<br/>
 </td>
 <td>
 </td>
@@ -43,18 +42,13 @@
 <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.36?view=revision&revision=227689">227689</a></td><td>lmadsen</td><td>Create 1.2.36 from 1.2.35 release.</td>
-<td></td></tr><tr><td><a href="http://svn.digium.com/view/asterisk/tags/1.2.36?view=revision&revision=227690">227690</a></td><td>lmadsen</td><td>Update ChangeLog and .version files.</td>
-<td></td></tr><tr><td><a href="http://svn.digium.com/view/asterisk/tags/1.2.36?view=revision&revision=227691">227691</a></td><td>file</td><td>Fix a security issue where sending a REGISTER with a differing username in the From</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/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>
 <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>
-.version            |    2 +-
-ChangeLog           |    6 ++++++
-channels/chan_sip.c |    2 --
-3 files changed, 7 insertions(+), 3 deletions(-)
+0 files changed
 </pre><br/>
 <hr/>
 </body>

asterisk-1.2.40-summary.txt

@@ -1,8 +1,8 @@
                                 Release Summary
 
-                                asterisk-1.2.36
+                                asterisk-1.2.40
 
-                                Date: 2009-11-04
+                                Date: 2010-02-18
 
                            <asteriskteam@digium.com>
 
@@ -28,10 +28,10 @@
    the advisories and determine what action they should take to protect their
    systems from these issues.
 
-   Security Advisories: AST-2009-008
+   Security Advisories: AST-2010-002
 
    The data in this summary reflects changes that have been made since the
-   previous release, asterisk-1.2.35.
+   previous release, asterisk-1.2.39.
 
      ----------------------------------------------------------------------
 
@@ -49,8 +49,7 @@
    release.
 
      Coders                   Testers                  Reporters              
-   2 lmadsen                
-   1 file                   
+   1 lmadsen                
 
      ----------------------------------------------------------------------
 
@@ -66,16 +65,8 @@
    +------------------------------------------------------------------------+
    | Revision | Author  | Summary                       | Issues Referenced |
    |----------+---------+-------------------------------+-------------------|
-   | 227689   | lmadsen | Create 1.2.36 from 1.2.35     |                   |
-   |          |         | release.                      |                   |
-   |----------+---------+-------------------------------+-------------------|
-   | 227690   | lmadsen | Update ChangeLog and .version |                   |
-   |          |         | files.                        |                   |
-   |----------+---------+-------------------------------+-------------------|
-   |          |         | Fix a security issue where    |                   |
-   | 227691   | file    | sending a REGISTER with a     |                   |
-   |          |         | differing username in the     |                   |
-   |          |         | From                          |                   |
+   | 247513   | lmadsen | Creating tag for the release  |                   |
+   |          |         | of asterisk-1.2.40            |                   |
    +------------------------------------------------------------------------+
 
      ----------------------------------------------------------------------
@@ -87,9 +78,6 @@
    This is a summary of the changes to the source code that went into this
    release that was generated using the diffstat utility.
 
- .version            |    2 +-
- ChangeLog           |    6 ++++++
- channels/chan_sip.c |    2 --
- 3 files changed, 7 insertions(+), 3 deletions(-)
+ 0 files changed
 
      ----------------------------------------------------------------------

channels/chan_iax2.c

@@ -824,8 +824,8 @@ static void jb_debug_output(const char *fmt, ...)
 
 
 /* XXX We probably should use a mutex when working with this XXX */
-static struct chan_iax2_pvt *iaxs[IAX_MAX_CALLS];
-static ast_mutex_t iaxsl[IAX_MAX_CALLS];
+static struct chan_iax2_pvt *iaxs[IAX_MAX_CALLS + 1];
+static ast_mutex_t iaxsl[IAX_MAX_CALLS + 1];
 
 /*!
  * \brief Another container of iax2_pvt structures
@@ -4037,7 +4037,7 @@ static int handle_call_token(struct ast_iax2_full_hdr *fh, struct iax_ies *ies,
 	/* ----- Case 3 ----- */
 	} else { /* calltokens are not supported for this client, how do we respond? */
 		if (calltoken_required(sin, ies->username, subclass)) {
-			ast_log(LOG_ERROR, "Call rejected, CallToken Support required. If unexpected, resolve by placing address %s in the calltokenignore list or setting user %s requirecalltoken=no\n", ast_inet_ntoa(iabuf, sizeof(iabuf), sin->sin_addr), ies->username);
+			ast_log(LOG_ERROR, "Call rejected, CallToken Support required. If unexpected, resolve by placing address %s in the calltokenignore list or setting user %s requirecalltoken=no\n", ast_inet_ntoa(iabuf, sizeof(iabuf), sin->sin_addr), ast_strlen_zero(ies->username) ? "guest" : ies->username);
 			goto reject;
 		}
 		return 0; /* calltoken is not required for this addr, so permit it. */
@@ -7634,6 +7634,7 @@ static int socket_read(int *id, int fd, short events, void *cbdata)
 	void *ptr;
 	socklen_t len = sizeof(sin);
 	int dcallno = 0;
+	char decrypted = 0;
 	struct ast_iax2_full_hdr *fh = (struct ast_iax2_full_hdr *)buf;
 	struct ast_iax2_mini_hdr *mh = (struct ast_iax2_mini_hdr *)buf;
 	struct ast_iax2_meta_hdr *meta = (struct ast_iax2_meta_hdr *)buf;
@@ -7833,6 +7834,25 @@ static int socket_read(int *id, int fd, short events, void *cbdata)
 
 		/* Get the destination call number */
 		dcallno = ntohs(fh->dcallno) & ~IAX_FLAG_RETRANS;
+
+
+		/* check to make sure this full frame isn't encrypted before we attempt
+ 		 * to look inside of it. If it is encrypted, decrypt it first. Its ok if the
+		 * callno is not found here, that just means one hasn't been allocated for
+		 * this connection yet. */
+		if ((dcallno != 1) && (fr->callno = find_callno(ntohs(mh->callno) & ~IAX_FLAG_FULL, dcallno, &sin, NEW_PREVENT, 1, fd, 1))) {
+			ast_mutex_lock(&iaxsl[fr->callno]);
+			if (ast_test_flag(iaxs[fr->callno], IAX_ENCRYPTED)) {
+				if (decrypt_frame(fr->callno, fh, &f, &res)) {
+					ast_log(LOG_NOTICE, "Packet Decrypt Failed!\n");
+					ast_mutex_unlock(&iaxsl[fr->callno]);
+					return 1;
+				}
+				decrypted = 1;
+			}
+			ast_mutex_unlock(&iaxsl[fr->callno]);
+		}
+
 		/* Retrieve the type and subclass */
 		f.frametype = fh->type;
 		if (f.frametype == AST_FRAME_VIDEO) {
@@ -7942,17 +7962,19 @@ static int socket_read(int *id, int fd, short events, void *cbdata)
 			ast_mutex_unlock(&iaxsl[fr->callno]);
 		return 1;
 	}
-	if (ast_test_flag(iaxs[fr->callno], IAX_ENCRYPTED)) {
+	if (ast_test_flag(iaxs[fr->callno], IAX_ENCRYPTED) && !decrypted) {
 		if (decrypt_frame(fr->callno, fh, &f, &res)) {
 			ast_log(LOG_NOTICE, "Packet Decrypt Failed!\n");
 			ast_mutex_unlock(&iaxsl[fr->callno]);
 			return 1;
 		}
-#ifdef DEBUG_SUPPORT
-		else if (iaxdebug)
-			iax_showframe(NULL, fh, 3, &sin, res - sizeof(*fh));
-#endif
+		decrypted = 1;
 	}
+#ifdef DEBUG_SUPPORT
+	if (decrypted && iaxdebug) {
+		iax_showframe(NULL, fh, 3, &sin, res - sizeof(*fh));
+	}
+#endif
 
 	/* count this frame */
 	iaxs[fr->callno]->frames_received++;

doc/IAX2-security.txt

@@ -0,0 +1,440 @@
+                                 IAX2 Security
+
+                       Copyright (c) 2009 - Digium, Inc.
+
+                              All Rights Reserved.
+
+                              Document Version 1.0
+
+                                    09/03/09
+
+              Asterisk Development Team <asteriskteam@digium.com>
+
+   Table of Contents
+
+   1. Introduction 3
+
+   1.1. Overview 3
+
+   2. User Guide 3
+
+   2.1. Configuration 3
+
+   2.1.1. Quick Start 3
+
+   2.1.2. Controlled Networks 4
+
+   2.1.2.1. Full Upgrade 4
+
+   2.1.2.2. Partial Upgrade 4
+
+   2.1.3. Public Networks 4
+
+   2.1.3.1. Full Upgrade 4
+
+   2.1.3.2. Partial Upgrade 5
+
+   2.1.3.3. Guest Access 5
+
+   2.2. CLI Commands 6
+
+   2.2.1. iax2 show callnumber usage 6
+
+   2.2.2. iax2 show peer 6
+
+   3. Protocol Modification 6
+
+   3.1. Overview 6
+
+   3.2. Call Token Validation 7
+
+   3.3. Example Message Exchanges 8
+
+   3.3.1. Call Setup 8
+
+   3.3.2. Call Setup, client does not support CALLTOKEN 8
+
+   3.3.3. Call Setup, client supports CALLTOKEN, server does not 9
+
+   3.3.4. Call Setup from client that sends invalid token 9
+
+   4. Asterisk Implementation 9
+
+   4.1. CALLTOKEN IE Payload 9
+
+                                1. Introduction
+
+1.1. Overview
+
+   A change has been made to the IAX2 protocol to help mitigate denial of
+   service attacks. This change is referred to as call token validation. This
+   change affects how messages are exchanged and is not backwards compatible
+   for an older client connecting to an updated server, so a number of
+   options have been provided to disable call token validation as needed for
+   compatibility purposes.
+
+   In addition to call token validation, Asterisk can now also limit the
+   number of connections allowed per IP address to disallow one host from
+   preventing other hosts from making successful connections. These options
+   are referred to as call number limits.
+
+   For additional details about the configuration options referenced in this
+   document, see the sample configuration file, iax.conf.sample. For
+   information regarding the details of the call token validation protocol
+   modification, see section 3 (Protocol Modification) of this document.
+
+                                 2. User Guide
+
+2.1. Configuration
+
+  2.1.1. Quick Start
+
+   We strongly recommend that administrators leave the IAX2 security
+   enhancements in place where possible. However, to bypass the security
+   enhancements completely and have Asterisk work exactly as it did before,
+   the following options can be specified in the [general] section of
+   iax.conf:
+
+   [general]
+
+   ...
+
+   calltokenoptional = 0.0.0.0/0.0.0.0
+
+   maxcallnumbers = 16382
+
+   ...
+
+  2.1.2. Controlled Networks
+
+   This section discusses what needs to be done for an Asterisk server on a
+   network where no unsolicited traffic will reach the IAX2 service.
+
+    2.1.2.1. Full Upgrade
+
+   If all IAX2 endpoints have been upgraded, then no changes to configuration
+   need to be made.
+
+    2.1.2.2. Partial Upgrade
+
+   If only some of the IAX2 endpoints have been upgraded, then some
+   configuration changes will need to be made for interoperability. Since
+   this is for a controlled network, the easiest thing to do is to disable
+   call token validation completely, as described in section 2.1.1.
+
+  2.1.3. Public Networks
+
+   This section discusses the use of the IAX2 security functionality on
+   public networks where it is possible to receive unsolicited IAX2 traffic.
+
+    2.1.3.1. Full Upgrade
+
+   If all IAX2 endpoints have been upgraded to support call token validation,
+   then no changes need to be made. However, for enhanced security, the
+   administrator may adjust call number limits to further reduce the
+   potential impact of malicious call number consumption. The following
+   configuration will allow known peers to consume more call numbers than
+   unknown source IP addresses:
+
+   [general]
+
+   ; By default, restrict call number usage to a low number.
+
+   maxcallnumbers = 16
+
+   ...
+
+   [callnumberlimits]
+
+   ; For peers with known IP addresses, call number limits can
+
+   ; be set in this section. This limit is per IP address for
+
+   ; addresses that fall in the specified range.
+
+   ; <IP>/<mask> = <limit>
+
+   192.168.1.0/255.255.255.0 = 1024
+
+   ...
+
+   [peerA]
+
+   ; Since we won't know the IP address of a dynamic peer until
+
+   ; they register, a max call number limit can be set in a
+
+   ; dynamic peer configuration section.
+
+   Type = peer
+
+   host = dynamic
+
+   maxcallnumbers = 1024
+
+   ...
+
+    2.1.3.2. Partial Upgrade
+
+   If only some IAX2 endpoints have been upgraded, or the status of an IAX2
+   endpoint is unknown, then call token validation must be disabled to ensure
+   interoperability. To reduce the potential impact of disabling call token
+   validation, it should only be disabled for a specific peer or user as
+   needed. By using the auto option, call token validation will be changed to
+   required as soon as we determine that the peer supports it.
+
+   [friendA]
+
+   requirecalltoken = auto
+
+   ...
+
+   Note that there are some cases where auto should not be used. For example,
+   if multiple peers use the same authentication details, and they have not
+   all upgraded to support call token validation, then the ones that do not
+   support it will get locked out. Once an upgraded client successfully
+   completes an authenticated call setup using call token validation,
+   Asterisk will require it from then on. In that case, it would be better to
+   set the requirecalltoken option to no.
+
+    2.1.3.3. Guest Access
+
+   Guest access via IAX2 requires special attention. Given the number of
+   existing IAX2 endpoints that do not support call token validation, most
+   systems that allow guest access should do so without requiring call token
+   validation.
+
+   [guest]
+
+   ; Note that the name "guest" is special here. When the code
+
+   ; tries to determine if call token validation is required, it
+
+   ; will look for a user by the username specified in the
+
+   ; request. Guest calls can be sent without a username. In
+
+   ; that case, we will look for a defined user called "guest" to
+
+   ; determine if call token validation is required or not.
+
+   type = user
+
+   requirecalltoken = no
+
+   ...
+
+   Since disabling call token validation for the guest account allows a huge
+   hole for malicious call number consumption, an option has been provided to
+   segregate the call numbers consumed by connections not using call token
+   validation from those that do. That way, there are resources dedicated to
+   the more secure connections to ensure that service is not interrupted for
+   them.
+
+   [general]
+
+   maxcallnumbers_nonvalidated = 2048
+
+2.2. CLI Commands
+
+  2.2.1. iax2 show callnumber usage
+
+   Usage: iax2 show callnumber usage [IP address]
+
+   Show current IP addresses which are consuming IAX2 call numbers.
+
+  2.2.2. iax2 show peer
+
+   This command will now also show the configured call number limit and
+   whether or not call token validation is required for this peer.
+
+                            3. Protocol Modification
+
+   This section discusses the modification that has been made to the IAX2
+   protocol. This information would be most useful to implementors of IAX2.
+
+3.1. Overview
+
+   The IAX2 protocol uses a call number to associate messages with which call
+   they belong to. The available amount of call numbers is finite as defined
+   by the protocol. Because of this, it is important to prevent attackers
+   from maliciously consuming call numbers. To achieve this, an enhancement
+   to the IAX2 protocol has been made which is referred to as call token
+   validation.
+
+   Call token validation ensures that an IAX2 connection is not coming from a
+   spoofed IP address. In addition to using call token validation, Asterisk
+   will also limit how many call numbers may be consumed by a given remote IP
+   address. These limits have defaults that will usually not need to be
+   changed, but can be modified for a specific need.
+
+   The combination of call token validation and call number limits is used to
+   mitigate a denial of service attack to consume all available IAX2 call
+   numbers. An alternative approach to securing IAX2 would be to use a
+   security layer on top of IAX2, such as DTLS [RFC4347] or IPsec [RFC4301].
+
+3.2. Call Token Validation
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119.
+
+   For this section, when the word "request" is used, it is referring to the
+   command that starts an IAX2 dialog.
+
+   This modification adds a new IAX2 frame type, and a new information
+   element be defined.
+
+   Frame Type: CALLTOKEN --- 0x28 (40)
+
+   IE: CALLTOKEN --- 0x36 (54)
+
+   When a request is initially sent, it SHOULD include the CALLTOKEN IE with
+   a zero-length payload to indicate that this client supports the CALLTOKEN
+   exchange. When a server receives this request, it MUST respond with the
+   IAX2 message CALLTOKEN. The CALLTOKEN message MUST be sent with a source
+   call number of 0, as a call number will not yet be allocated for this
+   call.
+
+   For the sake of backwards compatibility with clients that do not support
+   token validation, server implementations MAY process requests that do not
+   indicate CALLTOKEN support in their initial request. However, this SHOULD
+   NOT be the default behavior, as it gives up the security benefits gained
+   by CALLTOKEN validation.
+
+   After a client sends a request with an empty CALLTOKEN IE, it MUST be
+   prepared to receive a CALLTOKEN response, or to receive a response that
+   would be given in the case of a valid CALLTOKEN. This is how a client must
+   behave to inter operate with IAX2 server implementations that do not yet
+   support CALLTOKEN validation.
+
+   When an IAX2 client receives a CALLTOKEN response, it MUST send its
+   initial request again. This request MUST include the CALLTOKEN IE with a
+   copy of the value of the CALLTOKEN IE received in the CALLTOKEN response.
+   The IE value is an opaque value. Clients MUST be able to accept a
+   CALLTOKEN payload of any length, up to the maximum length allowed in an
+   IAX2 IE.
+
+   The value of the payload in the CALLTOKEN IE is an implementation detail.
+   It is left to the implementor to decide how sophisticated it should be.
+   However, it MUST be enough such that when the CALLTOKEN IE is sent back,
+   it can be used to verify that the source IP address and port number has
+   not been spoofed.
+
+   If a server receives a request with an invalid CALLTOKEN IE value, then it
+   MUST drop it and not respond.
+
+3.3. Example Message Exchanges
+
+  3.3.1. Call Setup
+
+   Client Server
+
+   -------- --------
+
+   ------------- NEW ----------->
+
+   (with empty CALLTOKEN IE)
+
+   <---------- CALLTOKEN ------------
+
+   (client must ignore
+
+   source call number
+
+   from this message)
+
+   ------------- NEW ----------->
+
+   (with received token)
+
+   <---------- AUTHREQ ----------
+
+   ... continue as normal ...
+
+  3.3.2. Call Setup, client does not support CALLTOKEN
+
+   Client Server
+
+   -------- --------
+
+   ------------- NEW ----------->
+
+   (with no CALLTOKEN IE)
+
+   <----------- REJECT ----------
+
+   (sent without allocating
+
+   a call number)
+
+   ------------- ACK ----------->
+
+  3.3.3. Call Setup, client supports CALLTOKEN, server does not
+
+   Client Server
+
+   -------- --------
+
+   ------------- NEW ----------->
+
+   (with empty CALLTOKEN IE)
+
+   <----------- AUTHREQ ---------
+
+   (sent without allocating
+
+   a call number)
+
+   ... continue as normal ...
+
+  3.3.4. Call Setup from client that sends invalid token
+
+   Client Server
+
+   -------- --------
+
+   ------------- NEW ----------->
+
+   (with invalid CALLTOKEN IE)
+
+   ... dropped ...
+
+                           4. Asterisk Implementation
+
+   This section includes some additional details on the implementation of
+   these changes in Asterisk.
+
+4.1. CALLTOKEN IE Payload
+
+   For Asterisk, we will encode the payload of the CALLTOKEN IE such that the
+   server is able to validate a received token without having to store any
+   information after transmitting the CALLTOKEN response. The CALLTOKEN IE
+   payload will contain:
+
+     * A timestamp (epoch based)
+
+     * SHA1 hash of the remote IP address and port, the timestamp, as well
+       some random data generated when Asterisk starts.
+
+   When a CALLTOKEN IE is received, its validity will be determined by
+   recalculating the SHA1 hash. If it is a valid token, the timestamp is
+   checked to determine if the token is expired. The token timeout will be
+   hard coded at 10 seconds for now. However, it may be made configurable at
+   some point if it seems to be a useful addition. If the server determines
+   that a received token is expired, it will treat it as an invalid token and
+   not respond to the request.
+
+   By using this method, we require no additional memory to be allocated for
+   a dialog, other than what is on the stack for processing the initial
+   request, until token validation is complete.
+
+   However, one thing to note with this CALLTOKEN IE encoding is that a token
+   would be considered valid by Asterisk every time a client sent it until we
+   considered it an expired token. However, with use of the "maxcallnumbers"
+   option, this is not actually a problem. It just means that an attacker
+   could hit their call number limit a bit quicker since they would only have
+   to acquire a single token per timeout period, instead of a token per
+   request.
+
+                                    10 of 10

funcs/func_strings.c

@@ -77,6 +77,44 @@ 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] = "";

pbx.c

@@ -4016,7 +4016,7 @@ static unsigned int get_day(char *day)
 		c++;
 	}
 	/* Find the start */
-	if (sscanf(day, "%1d", &s) != 1) {
+	if (sscanf(day, "%2d", &s) != 1) {
 		ast_log(LOG_WARNING, "Invalid day '%s', assuming none\n", day);
 		return 0;
 	}
@@ -4026,7 +4026,7 @@ static unsigned int get_day(char *day)
 	}
 	s--;
 	if (c) {
-		if (sscanf(c, "%1d", &e) != 1) {
+		if (sscanf(c, "%2d", &e) != 1) {
 			ast_log(LOG_WARNING, "Invalid day '%s', assuming none\n", c);
 			return 0;
 		}

rtp.c

@@ -348,7 +348,6 @@ static struct ast_frame *process_rfc3389(struct ast_rtp *rtp, unsigned char *dat
 	}
 	rtp->f.frametype = AST_FRAME_CNG;
 	rtp->f.subclass = data[0] & 0x7f;
-	rtp->f.datalen = len - 1;
 	rtp->f.samples = 0;
 	rtp->f.delivery.tv_usec = rtp->f.delivery.tv_sec = 0;
 	f = &rtp->f;