Re: [asterisk-users] Asterisk crash on core show channel

2018-02-21 Thread Patrick Wakano 
Thanks for you answer Marcus,
So maybe this means some bug was fixed? Anyone aware of something related?
>From the release notes, I couldn't find any direct change that could fix
this

Thanks,
Kind regards,
Patrick Wakano

On 21 February 2018 at 20:29, Marcus Kvarsell 
wrote:

> Hello, i found upgrading to asterisk 15 helped.
>
>
>
> *Från:* asterisk-users-boun...@lists.digium.com [mailto:asterisk-users-
> boun...@lists.digium.com] *För *Patrick Wakano
> *Skickat:* den 21 februari 2018 04:29
> *Till:* Asterisk Users Mailing List - Non-Commercial Discussion <
> asterisk-users@lists.digium.com>
> *Ämne:* [asterisk-users] Asterisk crash on core show channel
>
>
>
> Hello Asterisk list,
>
> I am facing some Asterisk crashes which are consistently pointing to the
> same backtrace, which is the following (using DONT_OPTIMIZE,
> BETTER_BACKTRACES and MALLOC_DEBUG):
> Thread 1 (Thread 0x7f1f08be8700 (LWP 1767)):
> #0  0x7f1f9bed3395 in __strcasecmp_l_sse42 () from /lib64/libc.so.6
> #1  0x004a91ca in cdr_object_get_by_name_cb ()
> #2  0x00463c60 in internal_ao2_traverse ()
> #3  0x00463fc3 in __ao2_callback ()
> #4  0x004a9b7d in cdr_object_get_by_name ()
> #5  0x004a9d80 in ast_cdr_serialize_variables ()
> #6  0x004de411 in handle_showchan ()
> #7  0x004e15a5 in ast_cli_command_full ()
> #8  0x004e175b in ast_cli_command_multiple_full ()
> #9  0x00455246 in netconsole ()
> #10 0x0060f192 in dummy_start ()
> #11 0x7f1f9cd3b9d1 in start_thread () from /lib64/libpthread.so.0
> #12 0x7f1f9be908fd in clone () from /lib64/libc.so.6
>
> So this happens after issuing a "core show channel ". This
> command is being executed by one script that periodically checks the
> channels and some of its variables. Thing is that sometimes the channel has
> something which causes this crash (happens around 2 times per month). Does
> anyone have any idea of what may be happening/wrong?
> I am running Asterisk version 13.6.0 on CentOS 6.6 kernel
> 2.6.32-504.el6.x86_64 and on CentOS 6.9 kernel 2.6.32-696.el6.x86_64.
>
> Any idea is very appreciated!
>
> Best regards,
>
> Patrick Wakano
>
>
>
>
>
>
> 
>
> Virus-free. www.avg.com
> 
>
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at: https://community.asterisk.
> org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> 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 --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] Queue playing periodic_announce to agent when they answer

2018-02-21 Thread Carlos Chavez 
    I have a very strange problem with my queues today.  When the agent 
answers a call they get the periodic_announce sound played to them.  I 
have a periodic_announce set to 60 seconds and the caller does hear it 
if their call is not answered.  Why would it play it to the agent?  At 
this point I even erased the periodic announcement but it is still being 
played:


[Feb 21 16:02:55] VERBOSE[25566][C-00c2] pbx.c: Executing 
[@incoming:1] Goto("PJSIP/MCM-01c0", "menu-corpo,s,1") in new stack
[Feb 21 16:02:55] VERBOSE[25566][C-00c2] pbx_builtins.c: Goto 
(menu-corpo,s,1)
[Feb 21 16:02:55] VERBOSE[25566][C-00c2] pbx.c: Executing 
[s@menu-corpo:1] Wait("PJSIP/MCM-01c0", "1") in new stack
[Feb 21 16:02:56] VERBOSE[25566][C-00c2] pbx.c: Executing 
[s@menu-corpo:2] Answer("PJSIP/MCM-01c0", "") in new stack
[Feb 21 16:02:56] VERBOSE[25566][C-00c2] pbx.c: Executing 
[s@menu-corpo:3] Set("PJSIP/MCM-01c0", "TIMEOUT(response)=5") in new 
stack
[Feb 21 16:02:56] VERBOSE[25566][C-00c2] func_timeout.c: Response 
timeout set to 5.000
[Feb 21 16:02:56] VERBOSE[25566][C-00c2] pbx.c: Executing 
[s@menu-corpo:4] Queue("PJSIP/MCM-01c0", "vacacional-corpo") in new 
stack
[Feb 21 16:02:56] VERBOSE[25566][C-00c2] res_musiconhold.c: Started 
music on hold, class 'default', on channel 'PJSIP/MCM-01c0'

[Feb 21 16:02:56] VERBOSE[25566][C-00c2] app_queue.c: Called PJSIP/1575
[Feb 21 16:02:56] VERBOSE[25566][C-00c2] app_queue.c: 
PJSIP/1575-01c1 is ringing
[Feb 21 16:03:00] VERBOSE[25566][C-00c2] app_queue.c: 
PJSIP/1575-01c1 answered PJSIP/MCM-01c0
[Feb 21 16:03:00] VERBOSE[25566][C-00c2] file.c: 
 Playing 'sullamada.slin' (language 'es')
[Feb 21 16:03:11] VERBOSE[25566][C-00c2] res_musiconhold.c: Stopped 
music on hold on PJSIP/MCM-01c0
[Feb 21 16:03:11] VERBOSE[25566][C-00c2] bridge_channel.c: Channel 
PJSIP/MCM-01c0 joined 'simple_bridge' basic-bridge 
<0559bfae-8b48-453f-8a1d-239a542edc99>
[Feb 21 16:03:14] VERBOSE[25566][C-00c2] bridge_channel.c: Channel 
PJSIP/MCM-01c0 left 'simple_bridge' basic-bridge 
<0559bfae-8b48-453f-8a1d-239a542edc99>
[Feb 21 16:03:14] VERBOSE[25566][C-00c2] pbx.c: Spawn extension 
(menu-corpo, s, 4) exited non-zero on 'PJSIP/MCM-01c0'


    We are using Realtime to configure Queues on Asterisk 13.19.1

--
Telecomunicaciones Abiertas de México S.A. de C.V.
Carlos Chávez
+52 (55)8116-9161


--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
 https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] AST-2018-006: WebSocket frames with 0 sized payload causes DoS

2018-02-21 Thread Asterisk Security Team 
   Asterisk Project Security Advisory - AST-2018-006

 ProductAsterisk  
 SummaryWebSocket frames with 0 sized payload causes DoS  
Nature of Advisory  Denial of Service 
  SusceptibilityRemote Unauthenticated Sessions   
 Severity   Moderate  
  Exploits KnownNo
   Reported On  February 05, 2018 
   Reported By  Sean Bright   
Posted On   February 21, 2018 
 Last Updated OnFebruary 21, 2018 
 Advisory Contact   bford AT digium DOT com   
 CVE Name   CVE-2018-7287 

Description  When reading a websocket, the length was not being checked.  
 If a payload of length 0 was read, it would result in a  
 busy loop that waited for the underlying connection to   
 close.   

Resolution  A patch to asterisk is available that checks for payloads of  
size 0 before attempting to read them. By default, Asterisk   
does not enable the HTTP server, which means it is not
vulnerable to this problem. If the HTTP server is enabled,
you can disable it if you do not need it. Otherwise, the  
patch provided with this security vulnerability can be
applied. Either of these approaches will resolve the  
problem.  

   Affected Versions   
 Product   Release  
   Series   
  Asterisk Open Source  15.xAll versions  

  Corrected In 
 Product  Release 
  Asterisk Open Source15.2.2  

Patches  
SVN URL  Revision 
   http://downloads.asterisk.org/pub/security/AST-2018-006-15.diff   Asterisk 
 15   

Links  https://issues.asterisk.org/jira/browse/ASTERISK-27658 
  
   http://downloads.asterisk.org/pub/security/AST-2018-006.html   

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at 
http://downloads.digium.com/pub/security/AST-2018-006.pdf and 
http://downloads.digium.com/pub/security/AST-2018-006.html

Revision History  
Date   EditorRevisions Made   
February 15, 2018 Ben Ford  Initial Revision  
February 21, 2018 Ben Ford  Added CVE Name

   Asterisk Project Security Advisory - AST-2018-006
   Copyright © 2018 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] AST-2018-005: Crash when large numbers of TCP connections are closed suddenly

2018-02-21 Thread Asterisk Security Team 
   Asterisk Project Security Advisory - AST-2018-005

 ProductAsterisk  
 SummaryCrash when large numbers of TCP connections are   
closed suddenly   
Nature of Advisory  Remote Crash  
  SusceptibilityRemote Authenticated Sessions 
 Severity   Moderate  
  Exploits KnownNo
   Reported On  January 24, 2018  
   Reported By  Sandro Gauci  
Posted On   February 21, 2018 
 Last Updated OnFebruary 21, 2018 
 Advisory Contact   gjoseph AT digium DOT com 
 CVE Name   CVE-2018-7286 

Description  A crash occurs when a number of authenticated INVITE 
 messages are sent over TCP or TLS and then the connection
 is suddenly closed. This issue leads to a segmentation   
 fault.   

Resolution  A patch to asterisk is available that prevents the crash by   
locking the underlying transport until a response is sent.

   Affected Versions
Product  Release Series  
 Asterisk Open Source 13.x   All Versions 
 Asterisk Open Source 14.x   All Versions 
 Asterisk Open Source 15.x   All Versions 
  Certified Asterisk 13.18   All Versions 

  Corrected In
 Product  Release 
   Asterisk Open Source   13.19.2, 14.7.6, 15.2.2 
Certified Asterisk  13.18-cert3   

 Patches  
SVN URL   Revision  
   http://downloads.asterisk.org/pub/security/AST-2018-005-13.diffAsterisk  
  13
   http://downloads.asterisk.org/pub/security/AST-2018-005-14.diffAsterisk  
  14
   http://downloads.asterisk.org/pub/security/AST-2018-005-15.diffAsterisk  
  15
   http://downloads.asterisk.org/pub/security/AST-2018-005-13.18.diff Certified 
  Asterisk  
  13.18 

 Linkshttps://issues.asterisk.org/jira/browse/ASTERISK-27618  
  
  http://downloads.asterisk.org/pub/security/AST-2018-005.html

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at 
http://downloads.digium.com/pub/security/AST-2018-005.pdf and 
http://downloads.digium.com/pub/security/AST-2018-005.html

Revision History
  Date  Editor Revisions Made 
February 6, 2018   George Joseph Initial Revision 

   Asterisk Project Security Advisory - AST-2018-005
   Copyright © 2018 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] AST-2018-004: Crash when receiving SUBSCRIBE request

2018-02-21 Thread Asterisk Security Team 
   Asterisk Project Security Advisory - AST-2018-004

  Product Asterisk
  Summary Crash when receiving SUBSCRIBE request  
 Nature of Advisory   Remote Crash
   Susceptibility Remote Unauthenticated Sessions 
  SeverityMajor   
   Exploits Known No  
Reported On   January 30, 2018
Reported By   Sandro Gauci
 Posted OnFebruary 21, 2018   
  Last Updated On February 21, 2018   
  Advisory ContactJoshua Colp
  CVE Name   CVE-2018-7284

Description  When processing a SUBSCRIBE request the res_pjsip_pubsub 
 module stores the accepted formats present in the Accept 
 headers of the request. This code did not limit the number   
 of headers it processed despite having a fixed limit of 32.  
 If more than 32 Accept headers were present the code would   
 write outside of its memory and cause a crash.   

Resolution  The res_pjsip_pubsub module has been changed to enforce a 
limit on the maximum number of Accept headers it will 
process. To receive this change upgrade to the version of 
Asterisk where this is resolved or apply the appropriate  
provided patch.   

   Affected Versions
Product  Release Series  
 Asterisk Open Source 13.x   All versions 
 Asterisk Open Source 14.x   All versions 
 Asterisk Open Source 15.x   All versions 
  Certified Asterisk 13.18   All versions 

  Corrected In
 Product  Release 
   Asterisk Open Source   13.19.2, 14.7.6, 15.2.2 
Certified Asterisk  13.18-cert3   

 Patches  
SVN URL   Revision  
   http://downloads.asterisk.org/pub/security/AST-2018-004-13.diffAsterisk  
  13
   http://downloads.asterisk.org/pub/security/AST-2018-004-14.diffAsterisk  
  14
   http://downloads.asterisk.org/pub/security/AST-2018-004-15.diffAsterisk  
  15
   http://downloads.asterisk.org/pub/security/AST-2018-004-13.18.diff Certified 
  Asterisk  
  13.18 

   Links https://issues.asterisk.org/jira/browse/ASTERISK-27640   

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at 
http://downloads.digium.com/pub/security/AST-2018-004.pdf and 
http://downloads.digium.com/pub/security/AST-2018-004.html

Revision History
  Date Editor  Revisions Made 
February 5, 2018   Joshua Colp  Initial Revision  
February 21, 2018  Joshua Colp  Added CVE 

   Asterisk Project Security Advisory - AST-2018-004
   Copyright © 2018 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users mailing list
To UNSUBSCRIBE or

[asterisk-users] AST-2018-003: Crash with an invalid SDP fmtp attribute

2018-02-21 Thread Asterisk Security Team 
   Asterisk Project Security Advisory - AST-2018-003

 ProductAsterisk  
 SummaryCrash with an invalid SDP fmtp attribute  
Nature of Advisory  Remote crash  
  SusceptibilityRemote Authenticated Sessions 
 Severity   Minor 
  Exploits KnownNo
   Reported On  January 15, 2018  
   Reported By  Sandro Gauci  
Posted On   February 21, 2018 
 Last Updated OnFebruary 19, 2018 
 Advisory Contact   Kevin Harwell 
 CVE Name   

Description  By crafting an SDP message body with an invalid fmtp 
 attribute Asterisk crashes when using the pjsip channel  
 driver because pjproject's fmtp retrieval function fails to  
 check if fmtp value is empty (set empty if previously
 parsed as invalid).  
  
 The severity of this vulnerability is lessened since an  
 endpoint must be authenticated prior to reaching the crash   
 point, or it's configured with no authentication.

Resolution  A stricter check is now done when pjproject retrieves the 
fmtp attribute. Empty values are now properly handled.

   Affected Versions   
 Product   Release  
   Series   
  Asterisk Open Source  13.xAll Releases  
  Asterisk Open Source  14.xAll Releases  
  Asterisk Open Source  15.xAll Releases  
   Certified Asterisk   13.18   All Releases  

  Corrected In
  Product  Release
Asterisk Open Source   13.19.2, 14.7.6, 15.2.2
 Certified Asterisk  13.18-cert3  

 Patches  
SVN URL   Revision  
   http://downloads.asterisk.org/pub/security/AST-2018-003-13.diffAsterisk  
  13
   http://downloads.asterisk.org/pub/security/AST-2018-003-14.diffAsterisk  
  14
   http://downloads.asterisk.org/pub/security/AST-2018-003-15.diffAsterisk  
  15
   http://downloads.asterisk.org/pub/security/AST-2018-003-13.18.diff Certified 
  Asterisk  
  13.18 

Links  https://issues.asterisk.org/jira/browse/ASTERISK-27583 

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at 
http://downloads.digium.com/pub/security/AST-2018-003.pdf and 
http://downloads.digium.com/pub/security/AST-2018-003.html

Revision History
 Date   Editor   Revisions Made   
January 30, 2018 Kevin Harwell  Initial Revision  

   Asterisk Project Security Advisory - AST-2018-003
  Copyright (c) 2018 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] AST-2018-002: Crash when given an invalid SDP media format description

2018-02-21 Thread Asterisk Security Team 
   Asterisk Project Security Advisory - AST-2018-002

 ProductAsterisk  
 SummaryCrash when given an invalid SDP media format  
description   
Nature of Advisory  Remote crash  
  SusceptibilityRemote Authenticated Sessions 
 Severity   Minor 
  Exploits KnownNo
   Reported On  January 15, 2018  
   Reported By  Sandro Gauci  
Posted On   February 21, 2018 
 Last Updated OnFebruary 19, 2018 
 Advisory Contact   Kevin Harwell 
 CVE Name   

Description  By crafting an SDP message with an invalid media format  
 description Asterisk crashes when using the pjsip channel
 driver because pjproject's sdp parsing algorithm fails to
 catch the invalid media format description.  
  
 The severity of this vulnerability is lessened since an  
 endpoint must be authenticated prior to reaching the crash   
 point, or it's configured with no authentication.

Resolution  Stricter validation is now done when pjproject parses an  
SDP's media format description. Invalid values are now
properly handled. 

   Affected Versions   
 Product   Release  
   Series   
  Asterisk Open Source  13.xAll Releases  
  Asterisk Open Source  14.xAll Releases  
  Asterisk Open Source  15.xAll Releases  
   Certified Asterisk   13.18   All Releases  

  Corrected In
  Product  Release
Asterisk Open Source   13.19.2, 14.7.6, 15.2.2
 Certified Asterisk  13.18-cert3  

 Patches  
SVN URL   Revision  
   http://downloads.asterisk.org/pub/security/AST-2018-002-13.diffAsterisk  
  13
   http://downloads.asterisk.org/pub/security/AST-2018-002-14.diffAsterisk  
  14
   http://downloads.asterisk.org/pub/security/AST-2018-002-15.diffAsterisk  
  15
   http://downloads.asterisk.org/pub/security/AST-2018-002-13.18.diff Certified 
  Asterisk  
  13.18 

Links  https://issues.asterisk.org/jira/browse/ASTERISK-27582 

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at 
http://downloads.digium.com/pub/security/AST-2018-002.pdf and 
http://downloads.digium.com/pub/security/AST-2018-002.html

Revision History
 Date   Editor   Revisions Made   
January 30, 2018 Kevin Harwell  Initial Revision  

   Asterisk Project Security Advisory - AST-2018-002
  Copyright (c) 2018 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

asterisk-users maili

[asterisk-users] AST-2018-001: Crash when receiving unnegotiated dynamic payload

2018-02-21 Thread Asterisk Security Team 
   Asterisk Project Security Advisory - AST-2018-001

  Product Asterisk
  Summary Crash when receiving unnegotiated dynamic payload   
 Nature of Advisory   Remote Crash
   Susceptibility Remote Unauthenticated Sessions 
  SeverityMajor   
   Exploits Known No  
Reported On   December 18, 2017   
Reported By   Sébastien Duthil
 Posted OnFebruary 21, 2018   
  Last Updated On February 21, 2018   
  Advisory ContactJoshua Colp
  CVE Name   CVE-2018-7285

Description  The RTP support in Asterisk maintains its own registry of
 dynamic codecs and desired payload numbers. While an SDP 
 negotiation may result in a codec using a different payload  
 number these desired ones are still stored internally. When  
 an RTP packet was received this registry would be consulted  
 if the payload number was not found in the negotiated SDP.   
 This registry was incorrectly consulted for all packets, 
 even those which are dynamic. If the payload number  
 resulted in a codec of a different type than the RTP stream  
 (for example the payload number resulted in a video codec
 but the stream carried audio) a crash could occur if no  
 stream of that type had been negotiated. This was due to 
 the code incorrectly assuming that a stream of the type  
 would always exist.  

Resolution  The RTP support will now only consult the registry for
payloads which are statically defined. The core has also  
been changed to protect against situations where a frame of   
media is received for a media type that has not been  
negotiated.   
  
To receive these fixes update to the given version of 
Asterisk or apply the provided patch. There is no 
configuration which can protect against this vulnerability.   

   Affected Versions
Product  Release Series  
 Asterisk Open Source 13.x   Unaffected   
 Asterisk Open Source 14.x   Unaffected   
 Asterisk Open Source 15.x   All versions 
  Certified Asterisk 13.18   Unaffected   

  Corrected In  
 Product  Release 
   Asterisk Open Source15.2.2 

Patches
   SVN URL  Revision  
   http://downloads.asterisk.org/pub/security/AST-2018-001-15.diff Asterisk   
   15 

   Links https://issues.asterisk.org/jira/browse/ASTERISK-27488   

Asterisk Project Security Advisories are posted at
http://www.asterisk.org/security  
  
This document may be superseded by later versions; if so, the latest  
version will be posted at 
http://downloads.digium.com/pub/security/AST-2018-001.pdf and 
http://downloads.digium.com/pub/security/AST-2018-001.html

Revision History
  Date Editor  Revisions Made 
January 15, 2018   Joshua Colp  Initial Revision  
February 21, 2018  Joshua Colp  Added CVE 

   Asterisk Project Security Advisory - AST-2018-001
   Copyright © 2018 Digium, Inc. All Rights Reserved.
  Permission is hereby granted to distribute and publish this advisory in its
   original, unaltered form.

-- 
__

[asterisk-users] Asterisk 13.19.2, 14.7.6, 15.2.2 and 13.18-cert3 Now Available (Security)

2018-02-21 Thread Asterisk Development Team 
The Asterisk Development Team would like to announce security releases for
Asterisk 13, 14 and 15, and Certified Asterisk 13.18. The available releases are
released as versions 13.19.2, 14.7.6, 15.2.2 and 13.18-cert3.

These releases are available for immediate download at

https://downloads.asterisk.org/pub/telephony/asterisk/releases
https://downloads.asterisk.org/pub/telephony/certified-asterisk/releases

The following security vulnerabilities were resolved in these versions:

* AST-2018-001: Crash when receiving unnegotiated dynamic payload
  The RTP support in Asterisk maintains its own registry of dynamic codecs and
  desired payload numbers. While an SDP negotiation may result in a codec using
  a different payload number these desired ones are still stored internally.
  When an RTP packet was received this registry would be consulted if the
  payload number was not found in the negotiated SDP. This registry was
  incorrectly consulted for all packets, even those which are dynamic. If the
  payload number resulted in a codec of a different type than the RTP stream
  (for example the payload number resulted in a video codec but the stream
  carried audio) a crash could occur if no stream of that type had been
  negotiated. This was due to the code incorrectly assuming that a stream of the
  type would always exist.

* AST-2018-002: Crash when given an invalid SDP media format description
  By crafting an SDP message with an invalid media format description Asterisk
  crashes when using the pjsip channel driver because pjproject's sdp parsing
  algorithm fails to catch the invalid media format description.

* AST-2018-003: Crash with an invalid SDP fmtp attribute
  By crafting an SDP message body with an invalid fmtp attribute Asterisk
  crashes when using the pjsip channel driver because pjproject's fmtp retrieval
  function fails to check if fmtp value is empty (set empty if previously parsed
  as invalid).

* AST-2018-004: Crash when receiving SUBSCRIBE request
  When processing a SUBSCRIBE request the res_pjsip_pubsub module stores the
  accepted formats present in the Accept headers of the request. This code did
  not limit the number of headers it processed despite having a fixed limit of
  32. If more than 32 Accept headers were present the code would write outside
  of its memory and cause a crash.

* AST-2018-005: Crash when large numbers of TCP connections are closed suddenly
  A crash occurs when a number of authenticated INVITE messages are sent over
  TCP or TLS and then the connection is suddenly closed. This issue leads to a
  segmentation fault.

* AST-2018-006: WebSocket frames with 0 sized payload causes DoS
  When reading a websocket, the length was not being checked. If a payload of
  length 0 was read, it would result in a busy loop that waited for the
  underlying connection to close.

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

https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-13.19.2
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-14.7.6
https://downloads.asterisk.org/pub/telephony/asterisk/releases/ChangeLog-15.2.2
https://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-certified-13.18-cert3

The security advisories are available at:

https://downloads.asterisk.org/pub/security/AST-2018-001.pdf
https://downloads.asterisk.org/pub/security/AST-2018-002.pdf
https://downloads.asterisk.org/pub/security/AST-2018-003.pdf
https://downloads.asterisk.org/pub/security/AST-2018-004.pdf
https://downloads.asterisk.org/pub/security/AST-2018-005.pdf
https://downloads.asterisk.org/pub/security/AST-2018-006.pdf

Thank you for your continued support of Asterisk!-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Modifying CDR values from a hangup extension in Asterisk 13

2018-02-21 Thread Olivier 
As a complement to my previous post, may I add that I observed the
following behaviours:

1. On one system (Debian Stretch/asterisk 13.19 compiled from source),
hangup causes are correctly saved in a custom CDR column.

2. On an other system (Debian Stretch/packaged asterisk), some rtcp stats
are not-correctly saved in a custom CDR column (I also tried unsuccessfully
with userfield column).

In both cases:
- CDR updates are triggered by a hangup handler pushed with
CHANNEL(hangup-handler-push).
- CDR are saved through ODBC i, aMariaDB or Postgres database.

Toughts ?

2018-02-21 0:07 GMT+01:00 Olivier :

> Hi,
>
> Reading this old thread, may I ask if keeping hangup handlers from
> updating CDR values still enforced in Asterisk 15 ?
> If positive, would it be very complex to add in Asterisk, a configuration
> option allowing a system administrator to list in cdr.conf, the CDR fields
> allowed to be updated in hangup handlers ?
>
> I'm planning to store some RTCP stats.
> Saving them in CDR(userfield) would be perfect.
>
> Cheers
>
>
> 2015-08-10 15:05 GMT+02:00 Matthew Jordan :
>
>>
>> On Tue, Aug 4, 2015 at 9:16 AM, Filip Jenicek  wrote:
>>
>>> With endbeforehexten=no I actually get two CDR entries. One for the call
>>> and a second one for the "h" extension.
>>> "","13","10","sip-locals","""13"" <13>","SIP/13-0006","SIP/1
>>> 0-0007","Dial","SIP/10","2015-08-04 06:28:44","2015-08-04
>>> 06:28:45","2015-08-04 06:28:47",3,1,"ANSWERED","DOCU
>>> MENTATION","1438669724.6","empty"
>>> "","13","h","sip-locals","""13"" 
>>> <13>","SIP/13-0006","","NoOp","changed","2015-08-04
>>> 06:28:47","2015-08-04 06:28:47","2015-08-04 06:28:47",0,0,"ANSWERED","DOCU
>>> MENTATION","1438669724.6","changed"
>>> The first one contains the call itself. There are durations, CDR
>>> variables set during the call, etc.
>>> The second one contains only things configured in the "h" extension.
>>>
>>> With endbeforehexten=yes, the cdr contains:
>>> "","13","10","sip-locals","""13"" <13>","SIP/13-0006","SIP/1
>>> 0-0007","Dial","SIP/10","2015-08-04 06:28:44","2015-08-04
>>> 06:28:45","2015-08-04 06:28:47",3,1,"ANSWERED","DOCU
>>> MENTATION","1438669724.6","empty"
>>> There is only the call, nothing from the "h" extension.
>>>
>>> I forgot to mention that I'm using Asterisk 13.1-cert2. Modifying CDR
>>> records in the "h" extension used to work fine with Asterisk 1.8.
>>>
>>> By analyzing the code I must confirm that the endbeforehexten option
>>> behaves exactly according to its description:
>>>  As each CDR for a channel is finished, its end time is updated
>>>  and the CDR is finalized. When a channel is hung up and hangup
>>>  logic is present (in the form of a hangup handler or the
>>>  h extension), a new CDR is generated for the
>>>  channel. Any statistics are gathered from this new CDR. By enabling
>>>  this option, no new CDR is created for the dialplan logic that is
>>>  executed in h extensions or attached hangup handler
>>>  subroutines. The default value is yes, indicating
>>>  that a CDR will be generated during hangup logic.
>>>
>>> I tried to delay the "h" extension by several seconds and I found out,
>>> that the CDR record is sent to the cdr backend later. Unfortunately, it is
>>> not modifiable from the "h" extension, because the cdr_object is already in
>>> the finalized table.
>>>
>>> Is there a way how to modify the CDR without hacking the code?
>>>
>>>
>> Unfortunately, no.
>>
>>
>>> How bad idea is it to comment the (it_cdr->fn_table ==
>>> &finalized_state_fn_table) tests in ast_cdr_setuserfield and ast_cdr_setvar
>>> and thus allow the "h" extension write to a finalized CDR?
>>>
>>>
>> Well... I'm not sure :-)
>>
>> As the guy who signed himself up for the dubious honour of porting the
>> CDR code to Asterisk 13 - and trying to figure out a consistent way to make
>> it work - I err'd on the side of extreme caution. That is, if someone could
>> make a mess of things, I should probably try to keep it from happening.
>>
>> A CDR can be finalized in a variety of ways:
>>  - Due to someone leaving a bridge
>>  - Due to a channel being hung up
>>  - Due to the CDR being forked
>>
>> Of those, modifying values is generally dangerous only in the "fork"
>> scenario, as it may result in a CDR that a user 'ended' being modified.
>> This is a concern when, as updating a value on a CDR walks the entire chain
>> of CDRs, for all CDRs related to the channel:
>>
>> for (; (cdr = ao2_iterator_next(it_cdrs)); ao2_unlock(cdr),
>> ao2_cleanup(cdr)) {
>> ao2_lock(cdr);
>> for (it_cdr = cdr; it_cdr; it_cdr = it_cdr->next) {
>> struct varshead *headp = NULL;
>>
>> if (it_cdr->fn_table == &finalized_state_fn_table) {
>> continue;
>> }
>> if (!strcasecmp(channel_name, it_cdr->party_a.snapshot->name))
>> {
>> headp = &it_cdr->party_a.variables;
>> } else if (it_cdr->party_b.snapshot
>> && !

Re: [asterisk-users] PJSIP issue - Syntax error exception when parsing

2018-02-21 Thread Social Boh 
hello,

you receive this error because the second line of SIP message not can
begin without a Header. You Phone or server (maybe OpenSIPs or Kamailio)
whet quitting a Via Header make some kind of error so the result is you
have the Via Header in two lines instead one.

Regards

---
I'm SoCIaL, MayBe

El 21/02/2018 a las 03:39, Michele Pinassi escribió:
> Hi all, i'm getting this error:
>
> [Feb 21 09:29:09] ERROR[1250]: pjproject:0 :       
> sip_transport.c Error processing 396 bytes packet from UDP
> 193.x:5060 : PJSIP syntax error exception when parsing '' header on
> line 2 col 1:
> SIP/2.0 480 User 7000 not registered
>
> Via: SIP/2.0/UDP
> 193.x:5060;received=193.xx;rport=5060;branch=z9hG4bKPjb092b027-a5b9-4683-8652-c7fefc06ae29
> From: ;tag=3d0a19e7-eabe-4446-84dd-43f02d831033
> To: ;tag=24eb447e8d0b8b1e81ba6efb9d8649a2.ea35
> Call-ID: defee3c7-e5ba-41ff-9be7-3c37e62437f2
> CSeq: 22011 INVITE
> Content-Length: 0
>
>
> -- end of packet.
>
> Asterisk 15.2.0 and PJSip 2.7.1
>
> Tnx, Michele
>
>
>

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Compiling 15.2.0 and 15.2.1 Fails Others are Fine

2018-02-21 Thread Joshua Colp 
On Tue, Feb 20, 2018, at 11:09 PM, David Klaverstyn wrote:
> Hi All,
> 
> When 15.2.0 was released I tried to upgrade as I do when new versions 
> are released but it failed to compile.  I figured it may be a bug so I 
> waited for the next release but 15.2.1 also fails in the same location.  
> I can download, and compile 15.1.5 no problems at all.  I'm not sure if 
> it is a 15.2.x problem or something else.
> 
> When I compile the following occurs which I could not find and answer for.
> 
> ./libasteriskpj.so: undefined reference to `initBcg729EncoderChannel'
> ./libasteriskpj.so: undefined reference to `bcg729Decoder'
> ./libasteriskpj.so: undefined reference to `bcg729Encoder'
> ./libasteriskpj.so: undefined reference to `initBcg729DecoderChannel'
> ./libasteriskpj.so: undefined reference to `closeBcg729EncoderChannel'
> ./libasteriskpj.so: undefined reference to `closeBcg729DecoderChannel'
> 
> 
> I am running this on a Raspberry Pi 3B, Raspbian 9.3 with Kernel 4.9.79-
> v7+ with all the latest updates.  I've been using the rPi for about four 
> or so years now and have not experienced a problem like this one.

This has been fixed[1] in the branch and will be in the next normal release. 
You can pull down the minor change from the review if you want. It tells PJSIP 
not to build with support for that.

[1] https://gerrit.asterisk.org/#/c/8193/

-- 
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] Asterisk crash on core show channel

2018-02-21 Thread Marcus Kvarsell 
Hello, i found upgrading to asterisk 15 helped.

Från: asterisk-users-boun...@lists.digium.com 
[mailto:asterisk-users-boun...@lists.digium.com] För Patrick Wakano
Skickat: den 21 februari 2018 04:29
Till: Asterisk Users Mailing List - Non-Commercial Discussion 

Ämne: [asterisk-users] Asterisk crash on core show channel

Hello Asterisk list,
I am facing some Asterisk crashes which are consistently pointing to the same 
backtrace, which is the following (using DONT_OPTIMIZE, BETTER_BACKTRACES and 
MALLOC_DEBUG):
Thread 1 (Thread 0x7f1f08be8700 (LWP 1767)):
#0  0x7f1f9bed3395 in __strcasecmp_l_sse42 () from /lib64/libc.so.6
#1  0x004a91ca in cdr_object_get_by_name_cb ()
#2  0x00463c60 in internal_ao2_traverse ()
#3  0x00463fc3 in __ao2_callback ()
#4  0x004a9b7d in cdr_object_get_by_name ()
#5  0x004a9d80 in ast_cdr_serialize_variables ()
#6  0x004de411 in handle_showchan ()
#7  0x004e15a5 in ast_cli_command_full ()
#8  0x004e175b in ast_cli_command_multiple_full ()
#9  0x00455246 in netconsole ()
#10 0x0060f192 in dummy_start ()
#11 0x7f1f9cd3b9d1 in start_thread () from /lib64/libpthread.so.0
#12 0x7f1f9be908fd in clone () from /lib64/libc.so.6
So this happens after issuing a "core show channel ". This command is 
being executed by one script that periodically checks the channels and some of 
its variables. Thing is that sometimes the channel has something which causes 
this crash (happens around 2 times per month). Does anyone have any idea of 
what may be happening/wrong?
I am running Asterisk version 13.6.0 on CentOS 6.6 kernel 2.6.32-504.el6.x86_64 
and on CentOS 6.9 kernel 2.6.32-696.el6.x86_64.
Any idea is very appreciated!
Best regards,
Patrick Wakano


[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-green-avg-v1.png]

Virus-free. 
www.avg.com


-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

Re: [asterisk-users] PJSIP issue - Syntax error exception when parsing

2018-02-21 Thread Khalil Khamlichi 
This error is caused by the phone sending an erroneous sip header not
by asterisk pjsip stack. solution would be to change the phone.

On Wed, Feb 21, 2018 at 8:39 AM, Michele Pinassi
 wrote:
> Hi all, i'm getting this error:
>
> [Feb 21 09:29:09] ERROR[1250]: pjproject:0 :
> sip_transport.c Error processing 396 bytes packet from UDP
> 193.x:5060 : PJSIP syntax error exception when parsing '' header on
> line 2 col 1:
> SIP/2.0 480 User 7000 not registered
>
> Via: SIP/2.0/UDP
> 193.x:5060;received=193.xx;rport=5060;branch=z9hG4bKPjb092b027-a5b9-4683-8652-c7fefc06ae29
> From: ;tag=3d0a19e7-eabe-4446-84dd-43f02d831033
> To: ;tag=24eb447e8d0b8b1e81ba6efb9d8649a2.ea35
> Call-ID: defee3c7-e5ba-41ff-9be7-3c37e62437f2
> CSeq: 22011 INVITE
> Content-Length: 0
>
>
> -- end of packet.
>
> Asterisk 15.2.0 and PJSip 2.7.1
>
> Tnx, Michele
>
> --
> Michele Pinassi
> Responsabile Telefonia di Ateneo
> Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi di 
> Siena
> tel: 0577.(23)5000 - central...@unisi.it
>
> Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di 
> Ateneo, http://www.faq.unisi.it
>
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> Check out the new Asterisk community forum at: https://community.asterisk.org/
>
> New to Asterisk? Start here:
>   https://wiki.asterisk.org/wiki/display/AST/Getting+Started
>
> 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 --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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

[asterisk-users] PJSIP issue - Syntax error exception when parsing

2018-02-21 Thread Michele Pinassi 
Hi all, i'm getting this error:

[Feb 21 09:29:09] ERROR[1250]: pjproject:0 :       
sip_transport.c Error processing 396 bytes packet from UDP
193.x:5060 : PJSIP syntax error exception when parsing '' header on
line 2 col 1:
SIP/2.0 480 User 7000 not registered

Via: SIP/2.0/UDP
193.x:5060;received=193.xx;rport=5060;branch=z9hG4bKPjb092b027-a5b9-4683-8652-c7fefc06ae29
From: ;tag=3d0a19e7-eabe-4446-84dd-43f02d831033
To: ;tag=24eb447e8d0b8b1e81ba6efb9d8649a2.ea35
Call-ID: defee3c7-e5ba-41ff-9be7-3c37e62437f2
CSeq: 22011 INVITE
Content-Length: 0


-- end of packet.

Asterisk 15.2.0 and PJSip 2.7.1

Tnx, Michele

-- 
Michele Pinassi
Responsabile Telefonia di Ateneo
Servizio Reti, Sistemi e Sicurezza Informatica - Università degli Studi di Siena
tel: 0577.(23)5000 - central...@unisi.it

Per trovare una soluzione rapida ai tuoi problemi tecnici consulta le FAQ di 
Ateneo, http://www.faq.unisi.it 




signature.asc
Description: OpenPGP digital signature
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

Check out the new Asterisk community forum at: https://community.asterisk.org/

New to Asterisk? Start here:
  https://wiki.asterisk.org/wiki/display/AST/Getting+Started

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