And including the SSH bug that also has been published today(http://www.cisco.com/warp/public/707/ssh-packet-suite-vuln.shtml.), it seems that a lot of networks will have a very "happy" xmas. ----- Original Message ----- From: "James-lists" <hackerwacker@cybermesa.com> To: <nanog@merit.edu> Sent: Thursday, December 19, 2002 6:50 PM Subject: Cisco IOS EIGRP Network DoS | | ----- Original Message ----- | From: "FX" <fx@phenoelit.de> | To: <bugtraq@securityfocus.com>; <darklab@darklab.org> | Sent: Thursday, December 19, 2002 10:06 AM | Subject: Cisco IOS EIGRP Network DoS | | | Hi there, | | please find attached an advisory about an issue with the Cisco IOS | Enhanced | IGRP implementation that can be used to cause a network segment wide | denial of | service condition. | | Regards | FX | | -- | FX <fx@phenoelit.de> | Phenoelit (http://www.phenoelit.de) | 672D 64B2 DE42 FCF7 8A5E E43B C0C1 A242 6D63 B564 | | Attached text moved here: | | | Phenoelit Advisory <wir-haben-auch-mal-was-gefunden #0815 +++-> | | [ Title ] | Cisco Systems IOS EIGRP Network Denial of Service | | [ Authors ] | FX <fx@phenoelit.de> | | Phenoelit Group (http://www.phenoelit.de) | Advisory http://www.phenoelit.de/stuff/CiscoEIGRP.txt | | [ Affected Products ] | Cisco IOS | | Tested on: IOS 11.3 | IOS 12.0(19) | IOS 12.2 | | Cisco Bug ID: <not assigned> | CERT Vu ID: <not assinged> | | [ Vendor communication ] | 10/08/02 Initial Notification, | gaus@cisco.com | 10/08/02 | - | 11/14/02 Communication with gaus@cisco.com about the issue, | fixes and timelines. | 12/18/02 Final advisory going public as coordinated release | *Note-Initial notification by phenoelit | includes a cc to cert@cert.org by default | | [ Overview ] | Cisco Systems IOS is vulnerable to a denial-of-service attack using | Cisco's proprietary routing protocol Enhanced IGRP (EIGRP). When | flooding a Cisco router with spoofed EIGRP neighbor announcements, | the router will cause an Address Resultion Protocol (ARP) storm on | the network segment while trying to find the MAC addresses for the | newly discovered neighbors, effectively using all available bandwidth. | | [ Description ] | EIGRP uses automatic discovery of neighboring routers. An EIGRP router | announces it's existence via multicast on the enabled interfaces. If | two routers discover each other, they try to exchange information | about the current topology in unicast. On Ethernet, both sides need | to obtain the MAC address of the other router. | | When generating EIGRP neighbor announcements with random source IP | addresses and flooding a Cisco router (unicast, only possible in 11.x) | or an entire network (multicast), all receiving Cisco routers will try | to contact the sender(s). The source IP addresses have to be in the | subnet(s) enabled via the "network" statement in the config of the | victim router. | | A bug in Cisco IOS causes the router to continiously try to obtain the | MAC address of the sender. This process does not time out unless the | EIGRP neighbor holdtimer expires. This value is supplied by the sender | of the neighbor announcement and has a maximum of over 18 hours. | | Multiple neighbor announcements with not existing source IP addresses | will cause the router to use all available CPU power and bandwidth on | the segment for ARP request - creating a segment-wide denial of | service condition. | | The possible use of IP multicast poses a high risk for larger | corporate networks using EIGRP. Cisco IOS versions below 12.0 also | accept EIGRP neighbor announcements as unicast packets, which makes | the attack possible via the Internet. | | [ Example ] | None provided at this time. | | [ Solution ] | Implement EIGRP authentication using MD5 hashes - which should have | been done in the first place. Where MD5 can not be implemented, use | extended access lists to match expected neighbors. | | The obvious workaround of using fixed neighbor entries in the | configuration does not work due to another bug in IOS that makes it | ignore the command (Cisco Bug ID CSCdv19648). | | [ end of file ($Revision: 1.5 $) ] | | | Cisco comments on Bug traq: | | -----BEGIN PGP SIGNED MESSAGE----- | | We can confirm the statement made by FX from Phenoelit in his message | "Cisco IOS EIGRP Network DoS" posted on 2002-Dec-19. The EIGRP | implementation in all versions of IOS is vulnerable to a denial of | service if it receives a flood of neighbor announcements. EIGRP is a | Ciscos' extension of IGP routing protocol used to propagate routing | information in internal network environments. | | The workaround for this issue is to apply MD5 authentication that will | permit the receipt of EIGRP packets only from authorized hosts. | You can find an example of how to configure MD5 authentication for | EIGRP at the following URL (possibly wrapped): | http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/ | np1_c/1cprt1/1ceigrp.htm#xtocid18 | | If you are using EIGRP in the unicast mode then you can mitigate | this issue by placing appropriate ACL which will block all EIGRP | packets from illegitimate hosts. In the following example the | EIGRP neighbor has IP address of 10.0.0.2 and the local router | has address 10.0.0.1. | | Router#config t | Router(config)#access-list 111 permit eigrp host 10.0.0.2 host 10.0.0.1 | Router(config)#access-list 111 deny eigrp any host 10.0.0.1 | | The previous example will permit all EIGRP packet throughout the router | and into the rest of the network. If you want to block these packets | as well then use the following commands instead of the previous | example: | | Router#config t | Router(config)#access-list 111 permit eigrp host 10.0.0.2 host 10.0.0.1 | Router(config)#access-list 111 deny eigrp any any | | An ACL will not be effective if you are using the default multicast | mode | of EIGRP neighbor discovery. However, multicast packets should not be | propagated through the Internet so an attacker must be on the same local | network segment as the target router in order to exploit this issue with | multicast advertisements. | | The issue with EIGRP neighbor command FX is referring to is assigned | Cisco Bug ID CSCdv19648 and is visible to all registered users through | Cisco's Bug Toolkit at | http://www.cisco.com/cgi-bin/Support/Bugtool/launch_bugtool.pl. | At the time of writing this notice Cisco PSIRT does not have a current | estimate on when the fix will be available. | | Gaus | | -----BEGIN PGP SIGNATURE----- | Version: PGP 6.5.3 | | iQEVAwUBPgIFTw/VLJ+budTTAQE7yggAiDxmo8MFD9rULZAG1PKcnn0wfHungE1a | dMfLN1oUaW7LYaMv+PJYkCvSO4t8oJlmQE9MXV3Q9VgLu9FHQDul3tzpOXMCmRB9 | 19H0XThGXzj7hDUbOrqgYXgDKQucarXg6yZ0nIuxNhEkl4XsnDohaMIkH7ynV/mY | mQ2qIehPw6aus2plvGDKDYZVTbClHk1qjTWhL3AgFqbVH9zkOHppLF47kP/adRlh | GeloUfxwMAJP2w4/MXObHMr9ELY+8mku/Fi0IBMfnZtS/VprZQZuvYQQmov7uYMV | VkvCoI/mkjkJGlTZyxHGtIbQGelC/eub+r4SiCxtH6APiFWaYWnwVw== | =o5+g | -----END PGP SIGNATURE----- | ============== | Damir Rajnovic <psirt@cisco.com>, PSIRT Incident Manager, Cisco Systems | <http://www.cisco.com/go/psirt> Telephone: +44 7715 546 033 | 200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB | ============== | There is no insolvable problems. | The question is can you accept the solution? | |