This Security Advisory describes multiple distinct vulnerabilities. These vulnerabilities are independent of each other.
A FWSM that has the HTTPS server enabled may reload if a crafted HTTP request is processed by the device. The HTTPS server is disabled by default.
The source IP address and interface on which the HTTPS request is received must comply with the configured http <source IP> <address mask> <source interface> command. For example, if the command http 10.10.10.0 255.255.255.0 inside is present in the configuration, then only crafted HTTPS requests coming from the 10.10.10.0/24 network may represent an issue for the device.
No other HTTP(s) services are known to be affected, such as HTTP Inspection, HTTP/HTTPS Proxy Server, and HTTP redirect.
To confirm if the HTTPS server is enabled, log in to the FWSM and issue the CLI command show running-config | include http. If the output contains both http server enable and http <source IP> <address mask> <source interface>, then the device has a vulnerable configuration. The following example shows an FWSM with a vulnerable configuration:
FWSM# show running-config | include http http server enable http 10.10.10.0 255.255.255.0 inside FWSM#
An FWSM that has the MGCP application layer protocol inspection feature enabled may reload when a crafted MGCP packet is processed by the device. MGCP application layer protocol inspection is not enabled by default.
MGCP messages are transmitted over the User Datagram Protocol (UDP), which does allow the crafted MGCP messages to be sourced from a spoofed address. Only the MGCP for gateway application (MGCP traffic on UDP port 2427) is affected.
To determine whether MGCP inspection is configured on the FWSM, log in to the device and issue the CLI command show service-policy | include mgcp. If the output contains the text Inspect: mgcp and some statistics, then the device has a vulnerable configuration. The following example shows a vulnerable FWSM:
FWSM# show service-policy | include mgcp Inspect: mgcp, packet 66, drop 0, reset-drop 0 FWSM#
This vulnerability is documented in Cisco Bug ID CSCsi00694 ( registered customers only) . The corresponding Cisco Bug ID for the PIX and ASA security appliances, included in the companion PIX/ASA Security Advisory, is CSCsi90468 ( registered customers only) .
This vulnerability may cause access control list entries (ACEs) in an ACL that has been manipulated to not be evaluated. Manipulation of the ACL can take place via the command-line interface or ASDM and consists of deleting and re-adding ACEs. When the access list is manipulated in this way, the internal structure that represents the ACL becomes corrupted, resulting in the FWSM not evaluating some ACEs.
Because ACEs in an ACL may not be evaluated, the ACL may allow traffic that would normally be denied, or deny traffic that would normally be permitted.
Filters that deny HTTPS packets using TCP port 443 and MGCP packets on UDP port 2427 should be deployed throughout the network as part of a transit ACL (tACL) policy for protection of traffic which enters the network at ingress access points. This policy should be configured to protect the network device where the filter is applied and other devices behind it. Filters for HTTPS packets using TCP port 443 and MGCP packets on UDP port 2427 should also be deployed in front of vulnerable network devices so that traffic is only allowed from trusted clients.
Additional information about tACLs is available in "Transit Access Control Lists : Filtering at Your Edge": http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801afc76.shtml.
Additional mitigations techniques that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory: http://tools.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20071017-asafwsm.
There are no workarounds for these vulnerabilities other than disabling the HTTPS server on the device. See the Cisco Applied Mitigation Bulletin companion document for mitigations.
Limiting the networks and hosts that can connect to the HTTPS server on the FWSM can help mitigate this vulnerability. For example, if the command http 10.10.10.0 255.255.255.0 inside is present in the configuration, then only hosts on this trusted network can establish HTTPS sessions with the FWSM. This scenario eliminates the possibility of malicious hosts on other IP networks launching successful attacks against the FWSM.
There is no workaround for this vulnerability other than disabling MGCP application layer protocol inspection on the device.
Leveraging anti-spoofing techniques will help mitigate spoofed packets from triggering this vulnerability.
Limiting MGCP application layer inspection to traffic between MGCP gateways may help to mitigate this vulnerability since it would require an attacker to have additional information (the addresses of the MGCP gateways) to launch a successful attack. To limit MGCP application layer inspection to traffic between certain devices, a class map that matches only traffic between the gateways must be created. Then, MGCP inspection must be performed on traffic in that class. The following example shows how to accomplish this:
FWSM(config)# access-list mgcp_traffic permit udp host 192.168.0.1 host 172.16.0.1 eq 2427 FWSM(config)# access-list mgcp_traffic permit udp host 172.16.0.1 host 192.168.0.1 eq 2427 FWSM(config)# class-map MGCP FWSM(config-cmap)# match access-list mgcp_traffic FWSM(config-cmap)# exit FWSM(config)# policy-map global_policy FWSM(config-pmap)# class inspection_default FWSM(config-pmap-c)# no inspect mgcp FWSM(config-pmap-c)# exit FWSM(config-pmap)# class MGCP FWSM(config-pmap-c)# inspect mgcp FWSM(config-pmap-c)# exit FWSM(config-pmap)# exit FWSM(config)#
Note that MGCP inspection is applied only to UDP traffic between hosts 192.168.0.1 and 172.16.0.1
See the Cisco Applied Mitigation Bulletin companion document for additional mitigation possibilities.
A possible workaround for this vulnerability is to completely remove the ACL before modifying it, and then recreate it with the desired changes. ACLs can be removed with the command clear configure access-list <ACL name>.
Note: The ACL corruption does not occur during normal operation of the device, and it cannot be triggered by some type of traffic. It can only occur if an administrator makes configuration changes, and more specifically, if an administrator manipulates an ACL. For this reason, if ACL changes are made only during a maintenance window and the FWSM is reloaded after making those changes, there should not be any concerns with this vulnerability.
When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution.
In all cases, customers should exercise caution to be certain that the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center ("TAC") or your contracted maintenance provider for assistance.
The following list contains the first fixed software release for each vulnerability:
Affected Major Release
First Fixed Release
Crafted HTTPS Request
Crafted MGCP packet
Manipulation of ACL May Cause ACL Corruption
3.2(3) - tentatively available Q4CY07
FWSM software versions 3.1(7) and 3.2(3) contain the fixes for all the vulnerabilities described in this document.
FWSM software is available for download from the following location on cisco.com: http://www.cisco.com/pcgi-bin/tablebuild.pl/cat6000-fwsm?psrtdcat20e2 ( registered customers only)
The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerabilities described in this advisory.
The crafted packet vulnerabilities were discovered by Cisco during internal testing of the associated products.
The ACL corruption vulnerability was discovered during the resolution of customer support cases.