Cisco IOS EIGRP Network DoS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
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 $) ]

[Index of Archives]     [Linux Security]     [Netfilter]     [PHP]     [Yosemite News]     [Linux Kernel]

  Powered by Linux