Cisco FWSM SCCP Inspection DoS Vulnerability

A vulnerability exists in the Cisco Firewall Services Module (FWSM) for the Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers that may cause the Cisco FWSM to reload after processing a malformed Skinny Client Control Protocol (SCCP) message. The vulnerability exists when SCCP inspection is enabled.

Cisco has released free software updates that address this vulnerability.

All non-fixed 4.x versions of Cisco FWSM Software are affected by this vulnerability if SCCP inspection is enabled. SCCP inspection is enabled by default.

To check if SCCP inspection is enabled, issue the show service-policy | include skinny command and confirm that the command returns output. Example output follows:

fwsm#show service-policy | include skinny
Inspect: skinny , packet 0, drop 0, reset-drop 0

If SCCP inspection is not required, this vulnerability can be mitigated by disabling it. Administrators can disable SCCP inspection by issuing the no inspect skinny command in class configuration sub-mode within the policy map configuration. If SCCP inspection is required, there are no workarounds.

Cisco has released free software updates that address this vulnerability. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment.

This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20100217-fwsm.shtml

Cisco Security Advisory: FWSM Crafted ICMP Message Vulnerability

Summary

A vulnerability exists in the Cisco Firewall Services Module (FWSM) for the Catalyst 6500 Series Switches and Cisco 7600 Series Routers. The vulnerability may cause the FWSM to stop forwarding traffic and may be triggered while processing multiple, crafted ICMP messages.

There are no known instances of intentional exploitation of this vulnerability. However, Cisco has observed data streams that appear to trigger this vulnerability unintentionally.

Cisco has released free software updates that address this vulnerability.

Successful exploitation of the vulnerability may cause the FWSM to stop forwarding traffic between interfaces (transit traffic), and stop processing traffic directed at the FWSM (management traffic). If the FWSM is configured for failover operation, the active FWSM may not fail over to the standby FWSM.

Workarounds

There are no workarounds for this vulnerability. Access control lists (ACLs) that are deployed on the FWSM itself to block through-the-device or to-the-device ICMP messages are not effective to prevent this vulnerability. However, blocking unnecessary ICMP messages on screening devices or on devices in the path to the FWSM will prevent the FWSM from triggering the vulnerability. For example, the following ACL, when deployed on a Cisco IOS device in front of the FWSM, will prevent crafted ICMP messages from reaching the FWSM, and thus protect the FWSM from triggering the vulnerability:

access-list 101 permit icmp any any echo
access-list 101 permit icmp any any echo-reply
access-list 101 permit icmp any any traceroute
access-list 101 permit icmp any any packet-too-big
access-list 101 permit icmp any any time-exceeded
access-list 101 permit icmp any any host-unreachable
access-list 101 permit icmp any any unreachable
access-list 101 deny   icmp any any
access-list 101 permit ip any any

The advisory is posted at the following link: http://www.cisco.com/en/US/products/products_security_advisory09186a0080af0d1d.shtml

Some personal observation regarding this vulnerability. I didn’t understood what they mean by “crafted” ICMP packets. In the advisory is posted that “There are no known instances of intentional exploitation of this vulnerability“, then what kind of ICMP packets would kill FWSM? Any usual “ping” (ICMP echo request / echo reply) or it has to be some packet with a special pattern?

If a special pattern is needed then there is a known exploitation of this vulnerability, but due to the fact that Cisco didn’t want any kiddie to try this, they didn’t release the information about what kind of ICMP traffic will foce FWSM to stop forwarding the traffic. In case that any ICMP packet might have an impact for FWSM functionality, then there is a big problem with this hardware.

Also their solution regarding ICMP blocking, cannot be applied in any case. I mean from my point of view as network engineer is OK, but from business impact may be bad, due to the fact that every user or manager use “ping” to check a running service, server or application. Imagine what will happen when 50% of the users will call for support that services are not running :)

UPDATE: Thanks to the comment of João Sena Ribeiro I noticed that the phrase (strikethrough) is a little bit confusing, as I put it in the context that I don’t  know what “ping” command will brind down the traffic through FWSM. If there is a known exploit for this (even if Cisco says there is none for the moment), a special pattern can be included also in a simple ICMP echo-request / echo-reply communication, causing the FWSM to hangup. So, if there is no solution for this vulnerability, I would like to block all ICMP traffic, but for the reasons already explained this would not be a good solution.

Cisco: FWSM CPU stress test how-to

Sometime ago I had to do a stress test for a Cisco FWSM (Firewall Service Module) to see how the resources are consumed and if some potential traffic can temporarly affect the behavior of this device. For those of you who have don’t know what is a Cisco FWSM, here comes the definition: “Cisco Firewall Services Module (FWSM)—a high-speed, integrated firewall module for Cisco Catalyst 6500 switches and Cisco 7600 Series routers—provides the fastest firewall data rates in the industry: 5-Gbps throughput, 100,000 CPS, and 1M concurrent connections”.

Since I didn’t had a hardware packets generator, I had to use a software one: IPerf . This is a tool that measure the maximum TCP or UDP bandwidth performance. Iperf allows the tuning of various parameters and UDP characteristics. Iperf reports bandwidth, delay jitter, datagram loss.Also it can run under Linux, Mac and Windows so the platform shouldn’t be a problem for you. As i said before, I used for testing my notebook as packet generator and a Linux server with DNS service enable as destination. Every packet from source (notebook) to destination (DNS server) was passing through FWSM, where it was inspect at OSI Layer 7  (DNS Application). Please check the topology file to have an idea about the configuration. Please be aware that if the packets (in our case DNS) are not to be inspected by FWSM, than the resource utilization of the FWSM is not so high, even in case of big traffic flow.

Please have a look below for the video presentation of the tutorial:

FWSM stress test how-to

If you cannot see the video tutorial above, please check this text file which present in text mode everything  needed to configure to do a stress test tool.