Workarounds consist of filtering packets that are sent to 127.0.0.0/8 range and UDP packets that are sent to port 1975.
Using Interface Access Control Lists
Access lists that filter UDP packets destined to port 1975 can be used to mitigate this vulnerability. UDP port 1975 is a registered port number that can be used by certain applications. However, filtering all packets that are destined to UDP port 1975 may cause some applications to malfunction. Therefore, access lists need to explicitly deny UDP 1975 packets that are sent to any router interface IP addresses and permit transit traffic. Such access lists need to be applied on all interfaces to be effective. Since the IPC channel uses addresses from the 127.0.0.0/8 range, it is also necessary to filter packets that are sourced from or destined to this range. An example is given below:
access-list 100 deny udp any host <router-interface 1> eq 1975
access-list 100 deny udp any host <router-interface 2> eq 1975
access-list 100 deny udp any host <router-interface ...> eq 1975
access-list 100 deny ip 127.0.0.0 0.255.255.255 any
access-list 100 deny ip any 127.0.0.0 0.255.255.255
access-list 100 permit ip any any
interface Serial 0/0
ip access-group 100 in
Using Control Plane Policing
Control Plane Policing (CoPP) can be used to block untrusted UDP port 1975 access to the affected device. Cisco IOS software releases 12.2BC and 12.2SCA support the CoPP feature. CoPP may be configured on a device to protect the management and control planes to minimize the risk and effectiveness of direct infrastructure attacks by explicitly permitting only authorized traffic sent to infrastructure devices in accordance with existing security policies and configurations. The following example can be adapted to your network.
Note: CoPP is not supported on uBR10012 series devices.
!-- Permit all UDP/1975 traffic so that it !-- will be policed and dropped by the CoPP feature
access-list 111 permit udp any any eq 1975
access-list 111 permit ip any 127.0.0.0 0.255.255.255
access-list 111 permit ip 127.0.0.0 0.255.255.255 any
!-- Permit (Police or Drop)/Deny (Allow) all other Layer 3 and !-- Layer 4 traffic in accordance with existing security policies !-- and configurations for traffic that is authorized to be sent !-- to infrastructure devices
!-- Create a Class-Map for traffic to be policed by the CoPP !-- feature
class-map match-all drop-IPC-class
match access-group 111
!-- Create a Policy-Map that will be applied to the Control-Plane !-- of the device
!-- Apply the Policy-Map to the Control-Plane of the device
service-policy input drop-IPC-traffic
In the above CoPP example, the access control list entries (ACEs) which match the potential exploit packets with the "permit" action result in these packets being discarded by the policy-map "drop" function, while packets that match the "deny" action (not shown) are not affected by the policy-map drop function.
Please note that in the Cisco IOS 12.2S and 12.0S trains the policy-map syntax is different:
policy-map drop-IPC-traffic class drop-IPC-class
police 32000 1500 1500 conform-action drop exceed-action drop
Additional information on the configuration and use of the CoPP feature can be found at http://www.cisco.com/web/about/security/intelligence/coppwp_gs.html, http://www.cisco.com/en/US/prod/collateral/iosswrel/ps6537/ps6586/ps6642/prod_white_paper0900aecd804fa16a.html and http://www.cisco.com/en/US/docs/ios/12_3t/12_3t4/feature/guide/gtrtlimt.html.
Using Infrastructure ACLs at Network Boundary
Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. iACLs are a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The iACL example shown below should be included as part of the deployed infrastructure access-list which will protect all devices with IP addresses in the infrastructure IP address range:
!-- Note: IPC packets sent to UDP destination port 1975 must not !-- be permitted from any trusted source as this traffic !-- should only be sent and received internally by the !-- affected device using an IP address allocated from the !-- 127.0.0.0/8 prefix. !-- !-- IPC that traffic that is internally generated and sent !-- and/or received by the affected device is not subjected !-- to packet filtering by the applied iACL policy.
!-- Deny IPC (UDP port 1975) packets from all sources destined to !-- all IP addresses configured on the affected device.
access-list 150 deny udp any host INTERFACE_ADDRESS#1 eq 1975
access-list 150 deny udp any host INTERFACE_ADDRESS#2 eq 1975
access-list 150 deny udp any host INTERFACE_ADDRESS#N eq 1975
!-- Deny all IP packets with a source or destination IP address !-- from the 127.0.0.0/8 prefix.
access-list 150 deny ip 127.0.0.0 0.255.255.255 any
access-list 150 deny ip any 127.0.0.0 0.255.255.255
!-- Permit/deny all other Layer 3 and Layer 4 traffic in accordance !-- with existing security policies and configurations.
!-- Permit all other traffic to transit the device.
access-list 150 permit ip any any
!-- Apply iACL to interfaces in the ingress direction.
ip access-group 150 in
Note: iACLs that filter UDP packets destined to port 1975 can be used to mitigate this vulnerability. However, UDP port 1975 is a registered port number that can be used by certain applications. Filtering all packets that are destined to UDP port 1975 may cause some applications to malfunction. Therefore, the iACL policy needs to explicitly deny UDP packets using a destination port of 1975 that are sent to any router interface IP addresses for affected devices, then permit and/or deny all other Layer 3 and Layer 4 traffic in accordance with existing security policies and configurations, and then permit all other traffic to transit the device. iACLs must be applied on all interfaces to be used effectively. Since the IPC channel uses addresses from the 127.0.0.0/8 range, it is also necessary to filter packets that are sourced from or destined to this range as provided in the preceding example.
The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for infrastructure protection access lists. This white paper can be obtained here:
Additional Mitigation Techniques
Additional mitigation techniques that can be deployed on Cisco devices within the network are available in the Cisco Applied Mitigation Bulletin companion document for this advisory, which is available at the following link: