----- 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?
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? | |
participants (2)
-
James-lists -
Rubens Kuhl Jr.