Cisco 10000, uBR10012, uBR7200 Series Devices IPC Vulnerability

Available Languages

Updated:November 9, 2014
Document ID:1454185971374109

Bias-Free Language

The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.

Cisco Security Advisory

Cisco 10000, uBR10012, uBR7200 Series Devices IPC Vulnerability

High
Advisory ID:
cisco-sa-20080924-ipc
First Published:
2008 September 24 16:00 GMT
Version 1.1:
Final
Workarounds:
See below
Cisco Bug IDs:
CSCsg15342
CSCsh29217
CVE-2008-3805
CVE-2008-3806
CVSS Score:
Base 8.5, Temporal 7.0Click Icon to Copy Verbose Score
AV:N/AC:L/Au:N/C:N/I:P/A:C/E:F/RL:OF/RC:C
CVE-2008-3805
CVE-2008-3806

Summary

Affected Products

  • Cisco 10000, uBR10012 and uBR7200 series devices that are running an affected version of Cisco IOS are affected.

    Vulnerable Products

    Devices that are running Cisco IOS can be identified by using the show version command. The following example shows an output taken from a Cisco 10000 series device running Cisco IOS software release 12.2(31)SB10e:

    c10k#show version | include IOS
Cisco IOS Software, 10000 Software (C10K3-P11-M), Version 12.2(31)SB10e, RELEASE SOFTWARE (fc1)
c10k#

    The following example shows an output taken from a Cisco uBR10012 series device running Cisco IOS software release 12.3(17b)BC7:

    ubr10k#show version | include IOS
IOS (tm) 10000 Software (UBR10K-K8P6U2-M), Version 12.3(17b)BC7, RELEASE SOFTWARE (fc1)
ubr10k#

    The following example shows an output taken from a Cisco uBR7200 series device running Cisco IOS software release 12.3(21a)BC2:

    ubr7200#show version | include IOS
IOS (tm) 7200 Software (UBR7200-IK9SU2-M), Version 12.3(21a)BC2, RELEASE SOFTWARE (fc1)
ubr7200#

    Please refer to the document entitled "White Paper: Cisco IOS Reference Guide" for additional information on the Cisco IOS release naming conventions. This document is available at the following link: http://www.cisco.com/warp/public/620/1.html

    Any version of Cisco IOS prior to the fixed versions listed in the Software Versions and Fixes section below is vulnerable.

    Products Confirmed Not Vulnerable

    Cisco uBR7100 series devices are not affected.

    No other Cisco products are currently known to be affected by this vulnerability.

Details

  • Cisco 10000, uBR10012 and uBR7200 series devices use a UDP-based IPC channel. This channel uses addresses from the 127.0.0.0/8 range and UDP port 1975. Cisco 10000, uBR10012 and uBR7200 series devices that are running an affected version of Cisco IOS will process IPC messages that are sent to UDP port 1975 from outside of the device. This behavior may be exploited by an attacker to cause a reload of the device, linecards, or both, resulting in a DoS condition.

    Filtering unauthorized traffic destined to 127.0.0.0/8 or UDP port 1975 will mitigate this vulnerability.

    This vulnerability is documented in the Cisco Bug IDs CSCsg15342 ( registered customers only) and CSCsh29217 ( registered customers only) and has been assigned Common Vulnerabilities and Exposures (CVE) ID CVE-2008-3805.

Workarounds

  • 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

!
policy-map drop-IPC-traffic
  class drop-IPC-class
    drop
!

!-- Apply the Policy-Map to the Control-Plane of the device

!
control-plane
  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.

!
interface GigabitEthernet0/0
  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:

    http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml

    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:

    https://sec.cloudapps.cisco.com/security/center/content/CiscoAppliedMitigationBulletin/cisco-amb-20080924-ipc-and-ubr

Fixed Software

Exploitation and Public Announcements

  • The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory.

    This vulnerability was found internally.

Cisco Security Vulnerability Policy

  • To learn about Cisco security vulnerability disclosure policies and publications, see the Security Vulnerability Policy. This document also contains instructions for obtaining fixed software and receiving security vulnerability information from Cisco.

Subscribe to Cisco Security Notifications

Action Links for This Advisory

Related to This Advisory

URL

Revision History

  • Revision 1.1

    2009-April-16

    Removed references to the combined software table, as it is now outdated

    Revision 1.0

    2008-Sep-24

    Initial public release.

    Show Less

Cisco Security Vulnerability Policy

  • To learn about Cisco security vulnerability disclosure policies and publications, see the Security Vulnerability Policy. This document also contains instructions for obtaining fixed software and receiving security vulnerability information from Cisco.

Subscribe to Cisco Security Notifications

Action Links for This Advisory

Related to This Advisory