[SR-Users] Asterisk Security Advisory (AST-2016-009)

[Daniel-Constantin Mierla]

Hello,

thanks, very useful!

Cheers,
Daniel


On 09/12/2016 00:02, Matthew Jordan wrote:
> Hey all -
>
> The Asterisk project just released a security advisory for a security
> vulnerability in which Asterisk using chan_sip with a proxy can allow
> for unauthenticated calls. This affects all supported versions of
> Asterisk (11, 13, 14). Since that may be relevant to those on this
> mailing list who are not also on the asterisk-users mailing list, I
> thought it prudent to mention it here as well.
>
> A description of the vulnerability follows:
>
>     Description  The chan_sip channel driver has a liberal definition for     
>                  whitespace when attempting to strip the content between a    
>                  SIP header name and a colon character. Rather than           
>                  following RFC 3261 and stripping only spaces and horizontal  
>                  tabs, Asterisk treats any non-printable ASCII character as   
>                  if it were whitespace. This means that headers such as       
>                                                                               
>                  Contact\x01:                                                 
>                                                                               
>                  will be seen as a valid Contact header.                      
>                                                                               
>                  This mostly does not pose a problem until Asterisk is        
>                  placed in tandem with an authenticating SIP proxy. In such   
>                  a case, a crafty combination of valid and invalid To         
>                  headers can cause a proxy to allow an INVITE request into    
>                  Asterisk without authentication since it believes the        
>                  request is an in-dialog request. However, because of the     
>                  bug described above, the request will look like an           
>                  out-of-dialog request to Asterisk. Asterisk will then        
>                  process the request as a new call. The result is that        
>                  Asterisk can process calls from unvetted sources without     
>                  any authentication.                                          
>                                                                               
>                  If you do not use a proxy for authentication, then this      
>                  issue does not affect you.                                   
>                                                                               
>                  If your proxy is dialog-aware (meaning that the proxy keeps  
>                  track of what dialogs are currently valid), then this issue  
>                  does not affect you.                                         
>                                                                               
>                  If you use chan_pjsip instead of chan_sip, then this issue   
>                  does not affect you.       
>
> The announcement can be seen here:
>
> http://lists.digium.com/pipermail/asterisk-announce/2016-December/000662.html
>
> Thanks again to Walter Doekes for reporting the vulnerability and
> providing the patch to fix it.
>
> Matt
>
> -- 
> Matthew Jordan
> Digium, Inc. | CTO
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20161209/656d1854/attachment.html>