bugtraq - Re: Re: Cisco VPN Concentrator IKE resource exhaustion DoS Advisory

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4a01982a0608111209q33ca5ac3sb47b7594adaa4e64@mail.gmail.com>
Date: Fri, 11 Aug 2006 12:09:37 -0700
From: "Henry Sieff" <henry.sieff@...il.com>
To: "Lance Seelbach" <lance@...inc.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: Re: Cisco VPN Concentrator IKE resource exhaustion DoS Advisory

Thank you for the response.

My question is "is it even a workaround."

Cisco's solution is to have the VPN concentrator refuse new SA
requests once the number of pending SA requests exceeds the set
amount. But the symptom of the DOS is that no new SA's can be formed.
So the workaround produces the same results as the DOS .

On 8/11/06, Lance Seelbach <lance@...inc.net> wrote:
> In reviewing the "fine print" of the Cisco response, their
> recommendations fall in the category of a workaround, since the
> underlying "vulnerability" is really a flaw in the IKE protocol.  Fix
> the protocol and you can fix the "vulnerability".  But that would
> require that every vendor who uses IKE to make changes too, which seems
> to make this a much broader issue than Cisco.
>
> L
>
> -----Original Message-----
> From: henry.sieff@...il.com
>
> Cisco recommends a workaround which essentially sets a limit on the
> number of outstanding SA's and drops new SA requests if they exceed that
> limit (outlined in
> http://www.cisco.com/en/US/products/sw/iosswrel/ps5207/products_feature_
> guide09186a0080229125.html)
>
>
> It seems to me that this will not accomplish much - presumably the
> determined attacker will simply continue to send packets - as soon as
> the number of SA'ss drops below that limit the attacker will simply fill
> up the queue again. Am I missing something about the vulnerability or
> the supposed fix from Cisco?
>