A denial-of-service vulnerability exists in the Hot Standby Router Protocol (HSRP) .
HSRP is a protocol designed to provide transparent recovery of routing services when failures occur. Quoting from RFC2281 (the RFC describing the Hot Standby Router Protocol):
The Hot Standby Router Protocol, HSRP, provides a mechanism which is designed to support nondisruptive failover of IP traffic in certain circumstances. In particular, the protocol protects against the failure of the first hop router when the source host cannot learn the IP address of the first hop router dynamically. The protocol is designed for use over multi-access, multicast or broadcast capable LANs (e.g., Ethernet). HSRP is not intended as a replacement for existing dynamic router discovery mechanisms and those protocols should be used instead whenever possible . A large class of legacy host implementations that do not support dynamic discovery are capable of configuring a default router. HSRP provides failover services to those hosts.
The following diagram depicts the topology of an IP network with two routers configured to use HSRP.
Our thanks to Cisco for permission to use this diagram.
HSRP-enabled routers operate by exchanging multicast messages amongst themselves that advertise their priority levels. By exchanging these messages, the participating routers determine which one of them is the default active router. The default priority level is typically 100, so if one of the participating routers is configured to have a priority of 101, that router will be the default active router. All HSRP-participating routers send a "hello" message using multicast every three seconds. If the default active router fails to send a "hello" message, the standby router with the next-highest priority will assume the role of being the active router. Because of this design flaw, it is possible for an attacker located on the same network segment as the routers participating in HSRP to disrupt network traffic. The vulnerability is best summarized in RFC2281:
This protocol does not provide security. The authentication field found within the message is useful for preventing misconfiguration. The protocol is easily subverted by an active intruder on the LAN. This can result in a packet black hole and a denial-of-service attack. It is difficult to subvert the protocol from outside the LAN as most routers will not forward packets addressed to the all-routers multicast address (18.104.22.168).
An attacker located on the same LAN segment as the routers using HSRP can disrupt legitimate network traffic resulting in a denial-of-service attack against the network infrastructure for which the participating routers are responsible for.
The CERT/CC is currently unaware of a practical solution to this problem.
Use HSRP in combination with IPsec as described in Advanced IPSec Deployment Scenarios.
Filter by status: All Affected Not Affected Unknown
Filter by content: __ Vendor has issued information
__ Sort by: Status Alphabetical
Affected Unknown __ Unaffected
Updated: December 13, 2001
We can confirm that described vulnerability is present in the HSRP
and, at the present time, there is no workaround for it. Customers
may consider using HSRP and IPsec combination as described in
<http://www.cisco.com/networkers/nw00/pres/2402.pdf> However, this
solution does not scale well.
Cisco is deliberating usage of IP authenticated header for HSRP
and VRRP (Virtual Router Redundancy Protocol, RFC2338) in the future
releases of IOS.
However, there are some other factors that must be considered in
- this vulnerability can be exploited only from the local segment
(not over the Internet),
- the same effect, denial of service, can be produced by using ARP,
which can not be protected in any way
The last issue is especially important since it may cause a false
sense of security if user is using a hardened version the protocol
(whichever protocol). Even by using VRRP and ESP+AH option, an
attacker can still disrupt the network by using ARP.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
If you have feedback, comments, or additional information about this vulnerability, please send us email.
Group | Score | Vector
Base | N/A | N/A
Temporal | N/A | N/A
Environmental | | N/A
The CERT/CC thanks Cisco Systems for their help in understanding this vulnerability.
This document was written by Ian A. Finlay.
CVE IDs:* | CVE-2001-0741
**Severity Metric: | 6.33
*Date Public: | 1998-03-01
Date First Published: | 2001-12-13
Date Last Updated: | 2001-12-18 13:47 UTC
Document Revision: | 85