[asterisk-users] Asterisk 1.8.28-cert2, 1.8.31.1, 11.6-cert7, 11.13.1, 12.6.1, 13.0.0-beta3 Now Available (Security Release)

2014-10-20 Thread Asterisk Development Team
The Asterisk Development Team has announced security releases for Certified
Asterisk 1.8.28 and 11.6 and Asterisk 1.8, 11, 12, and 13. The available
security releases are released as versions 1.8.28-cert2, 11.6-cert7, 1.8.31.1,
11.13.1, 12.6.1, and 13.0.0-beta3.

These releases are available for immediate download at
http://downloads.asterisk.org/pub/telephony/asterisk/releases

The release of these versions resolves the following security vulnerability:

* AST-2014-011: Asterisk Susceptibility to POODLE Vulnerability

  Asterisk is susceptible to the POODLE vulnerability in two ways:
  1) The res_jabber and res_xmpp module both use SSLv3 exclusively for their
 encrypted connections.
  2) The core TLS handling in Asterisk, which is used by the chan_sip channel
 driver, Asterisk Manager Interface (AMI), and Asterisk HTTP Server, by
 default allow a TLS connection to fallback to SSLv3. This allows for a
 MITM to potentially force a connection to fallback to SSLv3, exposing it
 to the POODLE vulnerability.

  These issues have been resolved in the versions released in conjunction with
  this security advisory.

For more information about the details of this vulnerability, please read
security advisory AST-2014-011, which was released at the same time as this
announcement.

For a full list of changes in the current releases, please see the ChangeLogs:

http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-1.8.28-cert2
http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-11.6-cert7
http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-1.8.31.1
http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-11.13.1
http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-12.6.1
http://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-13.0.0-beta3

The security advisory is available at:

 * http://downloads.asterisk.org/pub/security/AST-2014-011.pdf

Thank you for your continued support of Asterisk!


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] AST-2014-011: Asterisk Susceptibility to POODLE Vulnerability

2014-10-20 Thread Asterisk Security Team
   Asterisk Project Security Advisory - AST-2014-011

 ProductAsterisk  
 SummaryAsterisk Susceptibility to POODLE Vulnerability   
Nature of Advisory  Unauthorized Data Disclosure  
  SusceptibilityRemote Unauthenticated Sessions   
 Severity   Medium
  Exploits KnownNo
   Reported On  16 October 2014   
   Reported By  abelbeck  
Posted On   20 October 2014   
 Last Updated OnOctober 20, 2014  
 Advisory Contact   Matt Jordan mjordan AT digium DOT com   
 CVE Name   CVE-2014-3566 

   Description The POODLE vulnerability - described under CVE-2014-3566 - is  
   described at   
   https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566.  
   This advisory describes the Asterisk's project susceptibility  
   to this vulnerability. 
  
   The POODLE vulnerability consists of two issues:   
  
   1) A vulnerability in the SSL protocol version 3.0. This   
   vulnerability has no known solution.   
  
   2) The ability to force a fallback to SSLv3 when a TLS 
   connection is negotiated.  
  
   Asterisk is susceptible to both portions of the vulnerability  
   in different places.   
  
   1) The res_jabber and res_xmpp module both use SSLv3   
   exclusively, and are hence susceptible to POODLE.  
  
   2) The core TLS handling, used by the chan_sip channel driver, 
   Asterisk Manager Interface (AMI), and the Asterisk HTTP
   server, defaults to allowing SSLv3/SSLv2 fallback. This allows 
   a MITM to potentially force a connection to fallback to SSLv3, 
   exposing it to the POODLE vulnerability.   

Resolution  Asterisk has been patched such that it no longer uses SSLv3   
for the res_jabber/res_xmpp modules. Additionally, when the   
encryption method is not specified, the default handling in   
the TLS core no longer allows for a fallback to SSLv3 or  
SSLv2.
  
1) Users of Asterisk's res_jabber or res_xmpp modules should  
upgrade to the versions of Asterisk specified in this 
advisory. 
  
2) Users of Asterisk's chan_sip channel driver, AMI, and  
HTTP server may set the tlsclientmethod or  
sslclientmethod to tlsv1 to force TLSv1 as the only   
allowed encryption method. Alternatively, they may also   
upgrade to the versions of Asterisk specified in this 
advisory. Users of Asterisk are encouraged to NOT specify 
sslv2 or sslv3. Doing so will now emit a WARNING. 

   Affected Versions   
 Product   Release  
   Series   
  Asterisk Open Source  1.8.x   All versions  
  Asterisk Open Source  11.xAll versions  
  Asterisk Open Source  12.xAll versions  
   Certified Asterisk  1.8.28   All versions  
   Certified Asterisk   11.6All versions  

  Corrected In
  Product  

Re: [asterisk-users] CALLERID(num) and CDR(clid) - originate

2014-10-20 Thread Gabriel Ortiz Lour
All right Matt,
thanks

2014-10-03 5:37 GMT-03:00 Matthew Jordan mjor...@digium.com:

 On Wed, Oct 1, 2014 at 8:00 AM, Gabriel Ortiz Lour
 ortiz.ad...@gmail.com wrote:
  Hello,
 
A question on channel originating (call files and AMI Originate):
 
How can I change the CALLERID(num) var (because of the E1 provider
 needs),
  but having another númber (the original one) stored on the clid CDR
 field
  on the database?

 You can't. The clid CDR field cannot be modified from the dialplan,
 and is always set to the caller ID of the channel. If you change the
 caller ID on the channel, you can expect the CDR clid field to reflect
 that.

 That being said, if you are using a flexible backend (such as
 cdr_custom or cdr_adaptive_odbc), you can add a custom column to your
 CDR records - such as 'clid_original' - and use the CDR function to
 set that value prior to changing the caller ID:

 exten = Set(CDR(clid_original)=${CALLERID(num)})
 exten = Set(CALLERID(num)=6575309)

 Matt

 --
 Matthew Jordan
 Digium, Inc. | Engineering Manager
 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
 Check us out at: http://digium.com  http://asterisk.org

 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --
 New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello

 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 --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] bristuff-0.4.0-RC4-xr7

2014-10-20 Thread Ray Image
I am following the guide here:
http://updates.xorcom.com/astribank/bristuff/1.4/bristuff-current/INSTALL.html
for installing bristuff on a CentOS5.11 box (stock 2.6.18-398.el5.i686).
Whilst building zaptel I get the error as follows:

  CC [M]
 /usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel/xpp/card_bri.o
In file included from
/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel/xpp/xpd.h:26,
 from
/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel/xpp/card_bri.c:29:
/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel/xpp/xdefs.h:157:
error: conflicting types for ‘bool’
include/linux/types.h:36: error: previous declaration of ‘bool’ was here
In file included from
/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel/xpp/xpd.h:31,
 from
/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel/xpp/card_bri.c:29:
include/linux/device.h:407: error: expected identifier or ‘(’ before ‘const’
make[4]: ***
[/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel/xpp/card_bri.o]
Error 1
make[3]: ***
[/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel/xpp]
Error 2
make[2]: ***
[_module_/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649/kernel]
Error 2
make[2]: Leaving directory `/usr/src/kernels/2.6.18-398.el5-i686'
make[1]: *** [modules] Error 2
make[1]: Leaving directory
`/usr/src/bristuff-0.4.0-RC4-xr7/zaptel-1.4.12.9.svn.r4649'
make: *** [all] Error 2

Can anyone help please? Thanks in advance.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] TLS on SIP trunk

2014-10-20 Thread Meadows Hoa
Has anyone tried to create a SIP trunk between Asterisk and a CUCM? If so has 
anyone enabled tls on the trunk? Would the tlscafile field in the Asterisk 
sip.conf be used to refer to the pem file provided by the CUCM? Is the purpose 
of tlscafile to refer to the other call manager's pem file? Or would the 
tlscafile field need to refer to the ca.crt file created for Asterisk using the 
asterisk ssl tls scripts? Attempting to use self-signed certifications for both 
Asterisk and CUCM.  Does anyone know if the asterisk.pem file (created by using 
the asterisk ssl tls scripts and provided to the CUCM) needs to have the Issuer 
CN and Subject CN identical to avoid an Unknown CA error on the client key 
exchange?

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users