BugTraq
Cisco ACL bug when using VPN crypto engine accelerator, PPPoE dialer or ip route-cache May 14 2003 02:52PM
Olivier (itsce networkservices pmintl ch) (2 replies)
Re: Cisco ACL bug when using VPN crypto engine accelerator (NOT A BUG) May 15 2003 08:59AM
Jan Bervar (jan nil si)
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 (at) pmintl (dot) ch [email concealed]>
14.05.2003 16:52

To: bugtraq (at) securityfocus (dot) com [email concealed]
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.

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus