Document ID: 625
For Public Release 2007 May 2 16:00 UTC (GMT)
Status of this Notice: Final
Cisco Security Procedures
This is a Cisco response to a CERT/CC advisory posted on May 2, 2007, entitled "Cisco ASA fails to properly process DHCP relay packets". This advisory is available at the following link: http://www.kb.cert.org/vuls/id/530057
Cisco confirms the memory exhaustion vulnerability as per the advisory published by CERT/CC and confirms this vulnerability impacts the PIX and ASA appliance for system software 7.2 only. Exploitation of the vulnerability may lead to a Denial of Service condition against the appliance.
The Firewall Services Module (FWSM) is not affected by this vulnerability.
PSIRT would like to thank Grant Deffenbaugh and Lisa Sittler from the CERT/CC for reporting this vulnerability to Cisco.
We greatly appreciate the opportunity to work with researchers on security vulnerabilities, and welcome the opportunity to review and assist in security vulnerability reports against Cisco products.
The DHCP protocol supplies automatic configuration parameters such as an IP address, subnet mask, default gateway, DNS server address, and WINS address to hosts. Initially, DHCP clients have none of these configuration parameters. They obtain this information by sending a broadcast request for it. When a DHCP server sees this request, the DHCP server supplies the necessary information. Layer 3 devices such as routers and firewalls do not typically forward these broadcast requests by default.
In situations where it is not convenient to locate DHCP clients and DHCP servers upon the same subnet, PIX and ASA security appliances provide means for the use of a DHCP relay mechanism. When the DHCP relay agent receives the initial DHCPDISCOVER broadcast message on its configured listening interface from a DHCP client, it forwards the request to all of the specified DHCP server(s) located on another configured interface. The DHCP server(s) reply with a DHCPOFFER message, which the DHCP relay agent in turn forwards to the original DHCP client. The DHCP client then responds with a DHCPREQUEST broadcast message to select a specific DHCP proposal, which the DHCP relay agent also forwards to all of the DHCP server(s). The DHCP server with the selected lease then returns a DHCPACK, also forwarded by the DHCP relay agent, to tell the DHCP client that the lease is finalized.
If a client has obtained a network address through some other means (e.g., manual configuration), it may use a DHCPINFORM request message to obtain other local configuration parameters, which the DHCP relay agent also forwards to all of the DHCP server(s). The DHCP server(s) receiving the DHCPINFORM then return a DHCPACK message with any local configuration parameters appropriate for the client, also forwarded by the DHCP relay agent.
Thus, the DHCP relay agent acts as a proxy for the DHCP client in its conversation with the DHCP server(s).
A vulnerability exists in the PIX and ASA appliance system software when configured to use the DHCP relay agent functionality, where DHCPACK messages received from multiple DHCP servers in response to a DHCP client DHCPREQUEST or DHCPINFORM message may cause the 1550 byte block memory (Used to store Ethernet packets for processing through the security appliance) to be consumed. This may occur during normal device operations where affected versions are configured with more than one DHCP server via the dhcprelay server command. Once the 1550 byte block memory has been fully exhausted the appliance will start dropping packets and result in no packets being forwarding. Systems configured with only a single DHCP server via the dhcprelay server command are not vulnerable.
This vulnerability affects system software versions 7.2(1) through 7.2(2.14) inclusive.
Cisco has provided fixed system software - 7.2(2.15) or later, which is available for download from:
- ASA: http://www.cisco.com/pcgi-bin/tablebuild.pl/asa-interim
- PIX: http://www.cisco.com/pcgi-bin/tablebuild.pl/pix-interim
To determine if a PIX or ASA appliance is configured to use the DHCP relay agent feature, log in to the appliance and issue the command line interface (CLI) command show dhcprelay state. Systems returning information other than "not Configured for DHCP" are vulnerable. Alternatively, log in to the appliance and issue the CLI command show running-config dhcprelay.
The following examples show an appliance not configured for DHCP relay agent:
pix#show dhcprelay state Context Not Configured for DHCP Interface outside, Not Configured for DHCP Interface inside, Not Configured for DHCP pix# asa#show dhcprelay state Not Configured for DHCP asa#
The following example shows an appliance configured for DHCP relay agent:
asa#show dhcprelay state Context Configured as DHCP Relay Interface outside, Configured for DHCP RELAY Interface inside, Configured for DHCP RELAY SERVER asa#
The following example shows confirmation of an appliance configured for DHCP relay agent via the show running-config CLI command (An appliance not configured for DHCP relay agent will return nothing):
asa#show running-config dhcprelay dhcprelay server 10.2.1.2 outside dhcprelay enable inside dhcprelay timeout 60 asa#
The following example shows a response from an appliance not configured for DHCP relay agent:
asa#show running-config dhcprelay asa#
There are no workarounds for this vulnerability.
Having a single dhcprelay server configured as per the dhcprelay server command will prevent this vulnerability from being seen under normal operating conditions.
Provided below is an example of a system running with two dhcprelay servers configured, and applying the mitigation.
asa#show running-config dhcprelay dhcprelay server 192.168.200.210 inside dhcprelay server 192.168.200.200 inside dhcprelay enable outside dhcprelay timeout 60 asa(config)#no dhcprelay server 192.168.200.210 inside asa(config)#exit asa# asa#show running-config dhcprelay dhcprelay server 192.168.200.200 inside dhcprelay enable outside dhcprelay timeout 60 asa#
Any DHCP packet received on an interface that is not configured with a dhcprelay server command or dhcprelay enable will be dropped by the firewall.
Depending on your network environment, the use of ACLs or implementation of Anti-spoofing protections in the form of Infrastructure ACLs (iACLs) or Unicast Reverse Path Forwarding (Unicast RPF) will further mitigate the possibility of malicious exploitation from sources behind the interfaces configured with "dhcprelay server" command. More information on iACLs is available at Protecting Your Core: Infrastructure Protection Access Control Lists.
For information regarding Unicast RPF, please see IETF Best Current Practice 84, "Ingress Filtering for Multihomed Networks", at http://www.ietf.org/rfc/rfc3704.txt
Status of this Notice: Final
THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME.
A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors.
Initial public release
Cisco Security Procedures
Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt.