Is a control-plane ACL to limit isakmp traffic (UDP/500) to an affected ASA from desired sources enough to mitigate this attack, until upgrades can be performed? Regards, Andrew Ashley -----Original Message----- From: NANOG <nanog-bounces+andrew.a=aware.co.th@nanog.org> on behalf of Adrian M <adrian.minta@gmail.com> Date: Thursday, 11 February 2016 at 15:53 To: "nanog@nanog.org" <nanog@nanog.org> Subject: Re: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability

Be careful, It appears that something is broken with ARP on this release. We have no ARP on lan interface, and somebody else has a similar problem: https://www.reddit.com/r/networking/comments/433kqx/cisco_asa_not_recording_...

On Wed, Feb 10, 2016 at 10:36 PM, Sadiq Saif <lists@sadiqs.com> wrote:

...

Update your ASAs folks, this is a critical one.

-------- Forwarded Message -------- Subject: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability Date: Wed, 10 Feb 2016 08:06:51 -0800 From: Cisco Systems Product Security Incident Response Team <psirt@cisco.com> Reply-To: psirt@cisco.com To: cisco-nsp@puck.nether.net CC: psirt@cisco.com

Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability

Advisory ID: cisco-sa-20160210-asa-ike

Revision 1.0

For Public Release 2016 February 10 16:00 GMT (UTC)

+---------------------------------------------------------------------

Summary =======

A vulnerability in the Internet Key Exchange (IKE) version 1 (v1) and IKE version 2 (v2) code of Cisco ASA Software could allow an unauthenticated, remote attacker to cause a reload of the affected system or to remotely execute code.

The vulnerability is due to a buffer overflow in the affected code area. An attacker could exploit this vulnerability by sending crafted UDP packets to the affected system. An exploit could allow the attacker to execute arbitrary code and obtain full control of the system or to cause a reload of the affected system.

Note: Only traffic directed to the affected system can be used to exploit this vulnerability. This vulnerability affects systems configured in routed firewall mode only and in single or multiple context mode. This vulnerability can be triggered by IPv4 and IPv6 traffic.

Cisco has released software updates that address this vulnerability. This advisory is available at the following link:

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-s...

_______________________________________________ cisco-nsp mailing list cisco-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/cisco-nsp archive at http://puck.nether.net/pipermail/cisco-nsp/

Hi, First, understand how it's done, then maybe you can think of something. https://blog.exodusintel.com/2016/02/10/firewall-hacking/ If you are stopping IKE with ACL's, you probably need to address NAT-T as well (udp:4500). But if you are doing that, you probably don't need IKE active at the ASA, so just disabling it all together will probably do the trick.​ --- Best regards ​M​ arco Teixeira --- On Thu, Feb 11, 2016 at 6:06 PM, Dale W. Carder <dwcarder@wisc.edu> wrote:

Thus spake Andrew (Andy) Ashley (andrew.a@aware.co.th) on Thu, Feb 11, 2016 at 02:35:51PM +0000:

...

Is a control-plane ACL to limit isakmp traffic (UDP/500) to an affected ASA from desired sources enough to mitigate this attack, until upgrades can be performed?

It's worth noting that is not listed as a workaround (they typically use branding like "infrastructure acl's" or some such) to mitigate it on the affected box. Upstream, yes that would seem to be intuitive.

Perhaps because you are corrupting the heap with fragments you are outside of where the ACL is applied?

Dale