Date: Thu, 15 May 2003 10:59:40 +0200
From: "Jan Bervar" <jan@....si>
To: Olivier <itsce.networkservices@...ntl.ch>
Subject: Re: Cisco ACL bug when using VPN crypto engine accelerator (NOT A BUG)


Olivier,


I do not quite understand this. This is Cisco IOS *standard* behavior - 
when in IPsec tunnel mode, every packet should pass through the ACL twice 
- before, and after IPsec decapsulation. This gives you the *flexibility* 
to filter traffic which comes out of the tunnel as well - I regard this to 
be a good thing.

If this behavior does NOT show when the accelerator is disabled, that 
would be a bug (i.e. the reverse of what you believe is a bug).

If you are about to panic ;) and ask "is it now possible for (spoofed) 
cleartext traffic, which should be encrypted, to enter the interface and 
be permitted" the answer is no. The IOS crypto map automatically discards 
all traffic, which should have been encrypted according to the *crypto* 
ACL, but was not.

I have no idea why Cisco PSIRT responded as though this was a bug. It's a 
(not very well known) feature. It only works that way in tunnel mode, 
though. Transport mode packets (although not a lot of people would use 
that), decapsulated on the router, will only pass thru the ACL once.

Cheers,
Jan

Jan Bervar
Specialist za podatkovne komunikacije, CCIE #2527
Consulting Engineer

NIL Data Communications,  Einspielerjeva 6,  1000 Ljubljana,  Slovenia
Phone +386 1 4746 500       Fax +386 1 4746 501      http://www.NIL.si




Olivier <itsce.networkservices@...ntl.ch>
14.05.2003 16:52
 
        To:     bugtraq@...urityfocus.com
        cc: 
        Subject:        Cisco ACL bug when using VPN crypto engine 
accelerator, PPPoE    dialer or ip route-cache




Platform Cisco 1760 dual Ethernet 



IOS 12.2.xT IP/ADSL/FW/IDS PLUS IPSEC 3DES



Environment: Site to site VPN for small offices.



 



ACL are not properly parsed as soon as you enable:



crypto engine accelerator 

PPPoE dialer 

Ip route-cache 

 



Without the feature mentioned above, you can apply an ACL on the outside 

interface allowing only inbound ISAKMP and IPSEC traffic.



I.E. 



ip access-list extended Block-Inbound-unwanted-Trafic



 permit udp 100.100.100.0 0.0.0.255 host 102.168.1.2 eq isakmp



 permit esp 100.100. 100.0 0.0.0.255 host 102.168.1.2



 deny   ip any any log







If you activate the crypto engine, the ACL is parsed as well on decrypted 

traffic which forces you to allow as well all traffic for the decrypted 

traffic.

I.E. If you are using 10.x addressees internally and the subnet 

10.200.0.0/24 for your Soho LAN. Can be worst if you have a huge network 

inside where you would prefer to add permit ip  any 10.200.0.0 0.0.0.255.

 



ip access-list extended Block-Inbound-unwanted-Trafic

 permit udp 100.100.100.0 0.0.0.255 host 102.168.1.2 eq isakmp

 permit esp 100.100. 100.0 0.0.0.255 host 102.168.1.2

 permit ip  10.0.0.0 0.255.255.255 10.200.0.0 0.0.0.255 <-----------@...%@

 deny   ip any any log





This looks pretty bad for a VPN box running a Firewall feature set IOS 

seen as the best candidate for VPN for small offices.



The worst is the reply from Cisco:

-------------------------------------------------------------------

We will be addressing this in the next few months however

the release time frame could be as late as the end

of the year.

 

We do have plans to address it but do

not expect it in a released image until the

last calendar quarter of the year. If its possible we

can get it done and released sooner than what I've

mentioned, we will do it, no guarantees however.

------------------------------------------------------------------- 



We would have hope that they put more resources and concern in solving 

security issue.

Powered by blists - more mailing lists