[c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability

• Previous message (by thread): [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability
• Next message (by thread): [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 at wisc.edu> wrote:

> Thus spake Andrew (Andy) Ashley (andrew.a at 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
>

• Previous message (by thread): [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability
• Next message (by thread): [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer Overflow Vulnerability
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]