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

[Jan Gregor]

Hello all,

to anyone that might be interested, yesterday I ran to one of the issues
that Antoine mentioned. I have all my NAT translations configured like
this (typing by hand, so there might be slight typos, but you should get
the idea):

object-group network SERVICE_ALLOWED_HOSTS
  network-object 0.0.0.0 0.0.0.0

object service SERVICE_6000
  service tcp destination eq 6000

nat (OUTSIDE,DMZ) source static SERVICE_ALLOWED_HOSTS
SERVICE_ALLOWED_HOSTS destination static interface DMZ_SERVER service
SERVICE_6000 SERVICE_6000


The reason for such configuration is that I can use the same service
SERVICE_6000 in both NAT and access lists. In 9.1(6)10 this
configuration works perfectly. In 9.1(7) this configuration results in
ASA blocking all ARP on the DMZ interface:

arp-send: arp request built from X.X.X.41 Z for X.X.X.42 at 7212560
arp-in: response at DMZ from X.X.X.42 Y for X.X.X.41 Z having smac Y
dmac Z\n
 arp-in: src ip is same as one of nat mapped address X.X.X.42 .Consuming
the packet

The workaround is to configure NAT statements in 9.1(7) like this:
nat (OUTSIDE,DMZ) source static any any destination static interface
DMZ_SERVER service SERVICE_6000 SERVICE_6000

It works, but you lose option to alter hosts in SERVICE_ALLOWED_HOSTS
(for example when moving from test to production) without reconfiguring
the NAT statement.

Already trying to open case with Cisco.


Best regards,

Jan

On 02/16/2016 09:31 AM, Antoine Monnier wrote:
> Have heard, from cisco people themselves, that there are quite a few issues
> (NAT, ARP, ...) with the releases that fix this security hole.
> 
> I am surprised too that this hasn't made more noise.
> 
> On Tue, Feb 16, 2016 at 9:08 AM, Andrew (Andy) Ashley <andrew.a at aware.co.th>
> wrote:
> 
>> Hi,
>>
>> We upgraded a pair of 5515-X’s from 9.2(1) to 9.5(2)2, the interim
>> release, on Saturday.
>> Since then the free memory on the primary unit has been steadily
>> decreasing (30% -> 95% in 3 days).
>> These small increases appear to be happening around every 30 minutes or so.
>> We failed over to the standby, which had much lower memory usage but that
>> too is now creeping up.
>> The previous primary unit did not reclaim any memory and did not stop
>> climbing either after fail over.
>>
>> Have opened a TAC case but Wondering if it’s just us, or if this is
>> affecting others..
>>
>> Regards,
>> Andrew Ashley
>>
>>
>>
>>
>> -----Original Message-----
>> From: cisco-nsp <cisco-nsp-bounces at puck.nether.net> on behalf of Garry <
>> gkg at gmx.de>
>> Date: Tuesday, 16 February 2016 at 14:49
>> To: "cisco-nsp at puck.nether.net" <cisco-nsp at puck.nether.net>
>> Subject: Re: [c-nsp] Cisco Security Advisory: Cisco ASA Software IKEv1 and
>> IKEv2 Buffer Overflow Vulnerability
>>
>>> Hi,
>>>> On Wed, 2016-02-10 at 08:06 -0800, psirt at cisco.com wrote:
>>>>> Cisco Security Advisory: Cisco ASA Software IKEv1 and IKEv2 Buffer
>>>>> Overflow Vulnerability
>>>>>
>>>>> Advisory ID: cisco-sa-20160210-asa-ike
>>>> Poor bastards stuck at 8.2 (like us) might be relieved to know that
>>>> there actually is a 8.2(5)59 version with the fix. Reading the SA page
>>>> I got the impression that there was no fixed software for 8.2(5).
>>> Thanks for the find, same situation we were in (well, several of our
>>> customers rather) - reading the advisory, it clearly states anything 8.x
>>> except 8.4 is recommended to go to 9.1 (yeah, right! Not opening that
>>> can^H^H^H crate of worms! Or more like Pandora's box?). Apart from at
>>> least one system that only has 256M of RAM (and therefore can't go to
>>> anything higher than 8.2 AFAIK), even going to the mentioned 8.4.7(30)
>>> caused some problems due to incorrectly (or incomplete) config migration
>>> for several systems ... of course it could be fixed, but still ...
>>> And yes, the systems should be kept more current, but seeing what
>>> happens when you do update more or less confirms the old saying "never
>>> change a running system" ... sadly ...
>>>
>>> Still, if Cisco publishes an interim that fixes this disastrous flaw and
>>> is not at least following up on their announcement (8.2.5(59) was
>>> released 3 days after the initial notification was published), it's sort
>>> of a pain for users ... even the advisory on the web page hasn't been
>>> updated to at least list the option of using the interim ... :(
>>>
>>> -garry
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: not available
URL: <https://puck.nether.net/pipermail/cisco-nsp/attachments/20160216/49c904c0/attachment.sig>