Re: [asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
Is there a version of this patch for 1.6.2 - or did the recent 1.6.2 rc1 drop include it ? Tim. Tim Panton - Web/VoIP consultant and implementor www.westhawk.co.uk smime.p7s Description: S/MIME cryptographic signature ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
On Sunday 06 September 2009 12:31:05 Tim Panton wrote: Is there a version of this patch for 1.6.2 - or did the recent 1.6.2 rc1 drop include it ? There is. If you look in the security subdirectory on the downloads server, you'll find a patch for 1.6.2. No, rc1 of 1.6.2 was released too early to include the security patch. -- Tilghman Teryl with Peter, Cottontail, Midnight, Thumper, Johnny (bunnies) and Harry, BB, George (dogs) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
On Friday 04 September 2009 17:03:09 Gordon Henderson wrote: I've been hanging out with IAX, thinking it's the right thing, but more and more I'm thinking of moving to SIP, and I think this will be the straw that tips the balance as it were. I've a few 100 boxes out there which would all eventually need upgrading, and for some, it's just not going to be possible to upgrade the underlying asterisk, so it's going to be just as easy to move to SIP which is what I'm going to do. Just to be clear, this same attack is possible on SIP, although server resources are the limit there, instead of call number space. So with call tokens in place, IAX2 is now safer to use than SIP, in terms of an attacker attempting to exhaust your call resources. -- Tilghman Teryl with Peter, Cottontail, Midnight, Thumper, Johnny (bunnies) and Harry, BB, George (dogs) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
On Thu, 3 Sep 2009, Asterisk Security Team wrote: ++ | Discussion | A lot of time was spent trying to come up with a way to | || resolve this issue in a way that was completely backwards | || compatible. However, the final resolution ended up| || requiring a modification to the IAX2 protocol. This | || modification is referred to as call token validation. | || Call token validation is used as a handshake before call | || numbers are assigned to IAX2 connections. | Does this mean that if I upgrade one system, then I have to upgrade all of them because IAX will no-longer work between existing systems and upgraded ones? Gordon ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
4 sep 2009 kl. 08.05 skrev Gordon Henderson: On Thu, 3 Sep 2009, Asterisk Security Team wrote: + + | Discussion | A lot of time was spent trying to come up with a way to | || resolve this issue in a way that was completely backwards | || compatible. However, the final resolution ended up| || requiring a modification to the IAX2 protocol. This | || modification is referred to as call token validation. | || Call token validation is used as a handshake before call | || numbers are assigned to IAX2 connections. | Does this mean that if I upgrade one system, then I have to upgrade all of them because IAX will no-longer work between existing systems and upgraded ones? If you read the referenced document (the IAX2 security pdf) it says in the very first paragraph: 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. This means that you will have to configure your server to support older IAX2 users/peers. New servers will by default use the new version of the protocol (IAX3 ? :-) ) and will have to be configured to support the old style clients. 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. --- Thank you to the Digium team for a good documentation. I would kindly suggest to make it available in text format too, so that it's readable on consoles and in SSH sessions by confused admins that wonders what happens with IAX2 sessions... To the rest of you - please go read http://svn.digium.com/svn/asterisk/branches/1.6.0/doc/IAX2-security.pdf /O --- o...@edvina.net - http://edvina.net Open Unified Communication - building platforms with SIP and XMPP From PBX to large scale implementations for carriers. Contact us today! ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
On Fri, 4 Sep 2009, Olle E. Johansson wrote: 4 sep 2009 kl. 08.05 skrev Gordon Henderson: On Thu, 3 Sep 2009, Asterisk Security Team wrote: + + | Discussion | A lot of time was spent trying to come up with a way to | || resolve this issue in a way that was completely backwards | || compatible. However, the final resolution ended up| || requiring a modification to the IAX2 protocol. This | || modification is referred to as call token validation. | || Call token validation is used as a handshake before call | || numbers are assigned to IAX2 connections. | Does this mean that if I upgrade one system, then I have to upgrade all of them because IAX will no-longer work between existing systems and upgraded ones? If you read the referenced document (the IAX2 security pdf) it says in the very first paragraph: What, RTFM??? That would be cheating :) 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. This means that you will have to configure your server to support older IAX2 users/peers. New servers will by default use the new version of the protocol (IAX3 ? :-) ) and will have to be configured to support the old style clients. So if I configure it to support old ones, doesn't that still leave it vulnerable? 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. *sigh* I've been hanging out with IAX, thinking it's the right thing, but more and more I'm thinking of moving to SIP, and I think this will be the straw that tips the balance as it were. I've a few 100 boxes out there which would all eventually need upgrading, and for some, it's just not going to be possible to upgrade the underlying asterisk, so it's going to be just as easy to move to SIP which is what I'm going to do. I don't yet know what I'm going to do with the handfull of clients who use IAX and Zoiper though. Persuade them to move to SIP, I guess - at least Zoiper supports SIP now, but that's also a hassle as I've quite a few clients who use a SIP phone on their desk, then Zoiper and IAX on their laptop with identical credentials when on the road/home. (I arrange the PBX to Dial(SIP/123IAX2/123) And what about all those desk phones that support IAX? I almost bought a pallet-load of them at one point - really glad I didn't now! Gordon ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
On 5/09/09 10:03 AM, Gordon Henderson wrote: I've been hanging out with IAX, thinking it's the right thing, but more and more I'm thinking of moving to SIP, and I think this will be the straw that tips the balance as it were. I've a few 100 boxes out there which would all eventually need upgrading, and for some, it's just not going to be possible to upgrade the underlying asterisk, so it's going to be just as easy to move to SIP which is what I'm going to do. I don't yet know what I'm going to do with the handfull of clients who use IAX and Zoiper though. Persuade them to move to SIP, I guess - at least Zoiper supports SIP now, but that's also a hassle as I've quite a few clients who use a SIP phone on their desk, then Zoiper and IAX on their laptop with identical credentials when on the road/home. (I arrange the PBX to Dial(SIP/123IAX2/123) And what about all those desk phones that support IAX? I almost bought a pallet-load of them at one point - really glad I didn't now! To be fair, you should probably use something like Fail2Ban with either type of connection - SIP or IAX2. -- Cheers, Matt Riddell Director ___ http://www.venturevoip.com/news.php (Daily Asterisk News) http://www.venturevoip.com/st.php (SmoothTorque Predictive Dialer) http://www.venturevoip.com/c3.php (ConduIT3 PABX Systems) ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
On Fri, 4 Sep 2009, Gordon Henderson wrote: 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. Doesn't this introduce a new denial of service? If I (as the bad guy) connect (with call token validation) as a client that doesn't support CTV, how does the Admin remove the CTV requirement? I've been hanging out with IAX, thinking it's the right thing, but more and more I'm thinking of moving to SIP, and I think this will be the straw that tips the balance as it were. I've a few 100 boxes out there which would all eventually need upgrading, and for some, it's just not going to be possible to upgrade the underlying asterisk, so it's going to be just as easy to move to SIP which is what I'm going to do. I don't yet know what I'm going to do with the handfull of clients who use IAX and Zoiper though. Persuade them to move to SIP, I guess - at least Zoiper supports SIP now, but that's also a hassle as I've quite a few clients who use a SIP phone on their desk, then Zoiper and IAX on their laptop with identical credentials when on the road/home. (I arrange the PBX to Dial(SIP/123IAX2/123) And what about all those desk phones that support IAX? I almost bought a pallet-load of them at one point - really glad I didn't now! Hold on, Gordon :) I don't think the sky is falling on IAX yet. This just means that IAX is not appropriate for outward facing non-VPN connections without ACLs (iptables) that don't support CTV. -- Thanks in advance, - Steve Edwards sedwa...@sedwards.com Voice: +1-760-468-3867 PST Newline Fax: +1-760-731-3000 ___ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- AstriCon 2009 - October 13 - 15 Phoenix, Arizona Register Now: http://www.astricon.net asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] AST-2009-006: IAX2 Call Number Resource Exhaustion
Asterisk Project Security Advisory - AST-2009-006 ++ | Product | Asterisk | |+---| | Summary | IAX2 Call Number Resource Exhaustion | |+---| | Nature of Advisory | Denial of Service | |+---| | Susceptibility | Remote unauthenticated sessions | |+---| | Severity | Major | |+---| | Exploits Known | Yes - Published by Blake Cornell blake AT | || remoteorigin DOT com on voip0day.com| |+---| |Reported On | June 22, 2008 | |+---| |Reported By | Noam Rathaus noamr AT beyondsecurity DOT com , | || with his SSD program, also by Blake Cornell | |+---| | Posted On | September 3, 2009 | |+---| | Last Updated On | September 3, 2009 | |+---| | Advisory Contact | Russell Bryant russell AT digium DOT com | |+---| | CVE Name | CVE-2009-2346 | ++ ++ | Description | The IAX2 protocol uses a call number to associate| | | messages with the call that they belong to. However, the | | | protocol defines the call number field in messages as a | | | fixed size 15 bit field. So, if all call numbers are in | | | use, no additional sessions can be handled. | | | | | | A call number gets created at the start of an IAX2 | | | message exchange. So, an attacker can send a large | | | number of messages and consume the call number space.| | | The attack is also possible using spoofed source IP | | | addresses as no handshake is required before a call | | | number is assigned. | ++ ++ | Resolution | Upgrade to a version of Asterisk listed in this document | || as containing the IAX2 protocol security enhancements. In | || addition to upgrading, administrators should consult the | || users guide section of the IAX2 Security document | || (IAX2-security.pdf), as well as the sample configuration | || file for chan_iax2 that have been distributed with those | || releases for assistance with new options that have been | || provided. | ++ ++ | Discussion | A lot of time was spent trying to come up with a way to | || resolve this issue in a way that was completely backwards | || compatible. However, the final resolution ended up| || requiring a modification to the IAX2 protocol. This | || modification is referred to as call token validation. | || Call token validation is used as a handshake before call | || numbers are assigned to IAX2 connections. | || | || Call token validation by itself does not resolve the | || issue. However, it does allow an IAX2 server to validate | || that the source of the messages has not been spoofed. In | ||
