[NEWS] Cisco IOS Interface Blocked by IPv4 Packets

From: SecuriTeam (support_at_securiteam.com)
Date: 07/21/03

  • Next message: SecuriTeam: "[UNIX] Web Calendar Directory Traversal" 
    To: list@securiteam.com
Date: 21 Jul 2003 14:16:34 +0200

    The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com
    - - promotion

    Beyond Security in Canada

    Toronto-based Sunrays Technologies is now Beyond Security's representative in Canada.
    We welcome ISPs, system integrators and IT systems resellers
    to promote the most advanced vulnerability assessment solutions today.

    Contact us at 416-482-0038 or at canadasales@beyondsecurity.com

    - - - - - - - - -

      Cisco IOS Interface Blocked by IPv4 Packets
    ------------------------------------------------------------------------

    SUMMARY

    Cisco routers and switches running Cisco IOSŪ software and configured to
    process Internet Protocol version 4 (IPv4) packets are vulnerable to a
    Denial of Service (DoS) attack. Multiple IPv4 packets with specific
    protocol fields sent directly to the device may cause the input interface
    to stop processing traffic once the input queue is full. Traffic passing
    through the device cannot block the input queue. No authentication is
    required to process the inbound packet. Processing of IPv4 packets is
    enabled by default. Devices running only IP version 6 (IPv6) are not
    affected. Multiple valid workarounds are available in the form of best
    practices for situations where software upgrades are not currently
    feasible.

    Cisco has made software available, free of charge, to correct the problem.

    DETAILS

    Affected Products:
    This issue affects all Cisco devices running Cisco IOS software and
    configured to process Internet Protocol version 4 (IPv4) packets. This
    includes routers as well as switches and line cards that run Cisco IOS
    software. Cisco devices that do not run Cisco IOS software are not
    affected. Devices which run only Internet Protocol version 6 (IPv6) are
    not affected.

    To determine the software running on a Cisco product, log in to the device
    and issue the show version command to display the system banner. Cisco IOS
    software will identify itself as "Internetwork Operating System Software"
    or simply "IOSŪ". On the next line of output, the image name will be
    displayed between parentheses, followed by "Version" and the IOS release
    name. Other Cisco devices will not have the show version command or will
    give different output.

    The following example identifies a Cisco product running IOS release
    12.0(3) with an installed image name of C2500-IS-L:
    Cisco Internetwork Operating System Software IOS (TM)
     
    2500 Software (C2500-IS-L), Version 12.0(3), RELEASE SOFTWARE

    The release train label is "12.0".

    The next example shows a product running IOS release 12.0(2a)T1 with an
    image name of C2600-JS-MZ:

    Cisco Internetwork Operating System Software IOS (tm)

    C2600 Software (C2600-JS-MZ), Version 12.0(2a)T1, RELEASE SOFTWARE (fc1)

    Additional information about Cisco IOS Banners is available at
    <http://www.cisco.com/warp/public/620/4.html#banners>
    http://www.cisco.com/warp/public/620/4.html#banners.

    Details:
    Cisco routers are configured to process and accept Internet Protocol
    version 4 (IPv4) packets by default. IPv4 packets handled by the processor
    on a Cisco IOS device with protocol types of 53 (SWIPE), 55 (IP Mobility,
    or 77 (Sun ND), all with Time-to-Live (TTL) values of 1 or 0, and 103
    (Protocol Independent Multicast - PIM) with any TTL value, may force the
    device to incorrectly flag the input queue on an interface as full. A full
    input queue will stop the device from processing inbound traffic on that
    interface and may result in routing protocols dropping due to dead timers.

    Routers that have the PIM process running are not affected by traffic with
    protocol type 103. This process will be created when PIM is configured on
    any interface of the router. An interface with PIM enabled will have one
    of the following three commands in the interface configuration: ip pim
    dense-mode, ip pim sparse-mode, or ip pim sparse-dense-mode. Devices with
    input queues blocked with only PIM packets may have additional workaround
    options, which are listed in the Workarounds section.

    On a blocked Ethernet interface, Address Resolution Protocol (ARP) times
    out after a default time of four hours, and no traffic can be processed.
    The device must be rebooted to clear the input queue on the interface, and
    will not reload without user intervention. The attack may be repeated on
    all interfaces causing the router to be remotely inaccessible. A
    workaround is available, and is documented in the Workarounds section.
    Other types of interfaces, including but not limited to ATM, Serial and
    POS interfaces, may still be affected, but ARP is no longer a factor.

    The Cisco vulnerabilities are documented in the following two bug IDs:
    CSCea02355 (registered customers only) affects all Cisco routers running
    Cisco IOS software, documents the flaw with protocols 53, 55, and 77, and
    was introduced with bug ID CSCdi22941 (registered customers only).
    CSCdz71127 (registered customers only) was introduced by an earlier code
    revision, and documents an input queue vulnerability to protocol 103 with
    a device which is not configured for PIM. Any version of software which
    has the fix for CSCdx02283 (registered customers only) is vulnerable.

    To identify a blocked input interface, use the show interfaces command and
    look for the Input Queue line. If the current size (in this case, 76) is
    larger than the maximum size (75), the input queue is blocked.

    Use the show buffers command and look for the prot field. Below are two
    examples:

    Router#show interface ethernet 0/0
    Ethernet0/0 is up, line protocol is up
      Hardware is AmdP2, address is 0050.500e.f1e0 (bia 0050.500e.f1e0)
      Internet address is 172.16.1.9/24
      MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
      Encapsulation ARPA, loopback not set, keepalive set (10 sec)
      ARP type: ARPA, ARP Timeout 04:00:00
      Last input 00:00:41, output 00:00:07, output hang never
      Last clearing of "show interface" counters 00:07:18
      Input queue: 76/75/1091/0 (size/max/drops/flushes); Total output drops:
    0
    !--- The 76/75 shows that this is blocked

    Router#show buffers input-interface serial 0/0 packet
     Buffer information for Small buffer at 0x612EAF3C
     data_area 0x7896E84, refcount 1, next 0x0, flags 0x0
     linktype 7 (IP), enctype 0 (None), encsize 46, rxtype 0
     if_input 0x6159D340 (FastEthernet3/2), if_output 0x0 (None)
     inputtime 0x0, outputtime 0x0, oqnumber 65535
     datagramstart 0x7896ED8, datagramsize 728, maximum size 65436
     mac_start 0x7896ED8, addr_start 0x7896ED8, info_start 0x0
     network_start 0x7896ED8, transport_start 0x0
     source: 10.0.0.1, destination: 192.168.10.10, id: 0xAAB8, ttl: 41, prot:
    103

    !--- prot: 103 is proof that this is one of the attack packets

    Impact:
    A device receiving these specifically crafted IPv4 packets will force the
    inbound interface to stop processing traffic. The device may stop
    processing packets destined to the router, including routing protocol
    packets and ARP packets. No alarms will be triggered, nor will the router
    reload to correct itself. This issue can affect all Cisco devices running
    Cisco IOS software. This vulnerability may be exercised repeatedly
    resulting in loss of availability until a workaround has been applied or
    the device has been upgraded to a fixed version of code.

    Software Versions and Fixes
    Each row of the table describes a release train and the platforms or
    products for which it is intended. If a given release train is vulnerable,
    then the earliest possible releases that contain the fix and the
    anticipated date of availability for each are listed in the Rebuild,
    Interim, and Maintenance columns. In some cases, no rebuild of a
    particular release is planned; this is marked with the label "Not
    scheduled." A device running any release in the given train that is
    earlier than the release in a specific column (less than the earliest
    fixed release) is known to be vulnerable, and it should be upgraded at
    least to the indicated release or a later version (greater than the
    earliest fixed release label).

    A table listing all affected products and their corresponding fixes is
    available at:
    <http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml>
    http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml

    Obtaining Fixed Software
    Customers with contracts should obtain upgraded software free of charge
    through their regular update channels. For most customers, this means that
    upgrades should be obtained through the Software Center on the Cisco
    worldwide website at
    <http://www.cisco.com/tacpage/sw-center/sw-ios.shtml>
    http://www.cisco.com/tacpage/sw-center/sw-ios.shtml.

    Customers whose Cisco products are provided or maintained through prior or
    existing agreement with third-party support organizations such as Cisco
    Partners, authorized resellers, or service providers should contact that
    support organization for assistance with obtaining the free software
    upgrade(s).

    Customers who purchase direct from Cisco but who do not hold a Cisco
    service contract and customers who purchase through third-party vendors
    but are unsuccessful at obtaining fixed software through their point of
    sale should get their upgrades by contacting the Cisco Technical
    Assistance Center (TAC). TAC contacts are as follows.
     * +1 800 553 2447 (toll free from within North America)
     * +1 408 526 7209 (toll call from anywhere in the world)
     * e-mail: tac@cisco.com

    Please have your product serial number available and give the URL of this
    notice as evidence of your entitlement to a free upgrade. To ensure prompt
    service by email or by phone, please provide your name, company name,
    address, product serial number, and current version of Cisco IOS software
    that you are using. This can be documented by pasting the output of the
    show version command into the text of an email. Free upgrades for
    non-contract customers must be requested through the TAC.

    Please do not contact either "psirt@cisco.com" or
    "security-alert@cisco.com" for software upgrades.

    See <http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml>
    http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional
    TAC contact information, including special localized telephone numbers,
    instructions, and e-mail addresses for use in various languages.

    Workarounds
    Cisco recommends that all IOS devices that process IPv4 packets be
    configured to block unwanted traffic, or any traffic directed to the
    router from an unauthorized source with the use of Access Control Lists
    (ACLs). This can be done at multiple locations, and it is recommended that
    you review all methods and use the combination that fits your network
    best. Although the following ACLs are listed as a workaround for this
    vulnerability, in cases where performance is not impacted, these
    techniques can be considered best practices and may be left in place as a
    long-term solution rather than a temporary fix.

    Best practices dictate that legitimate traffic is defined as management
    protocols such as telnet, snmp, or ssh, and configured routing protocols
    from explicitly allowed peers. All other traffic destined to the device
    should be blocked at the input interface. Traffic entering the network
    should also be carefully evaluated and filtered at the network edge if
    destined to an infrastructure device. Although network service providers
    must often allow unknown traffic to transit their network, it is not
    necessary to allow that same traffic destined to their network
    infrastructure. Several white papers have been written to assist in
    deploying these recommended security best practices.

    For devices with interfaces that are currently blocked due to exploitation
    of this vulnerability, ACL workarounds may be applied. AFTER APPLYING THE
    WORKAROUND, the input queue depth may be raised with the hold-queue in
    interface command to something larger than the default size of 75. This
    will allow traffic flow on the interface. The device may then be reloaded
    at a convenient time to release the blocked packets.

    For interfaces blocked with PIM packets only, the PIM process may be
    enabled on the router after applying a workaround that will clear protocol
    type 103 packets from the blocked input queue. This does not clear packets
    with protocol type 53, 55, or 77 from the input queue. Although a device
    with PIM enabled is not vulnerable to attacks with protocol 103 packets,
    enabling PIM is not recommended as a workaround to this vulnerability, as
    it does not block protocols 53, 55, or 77, and may have performance
    implications.

    ACLs can have performance impact on certain platforms, so care should be
    taken when applying the recommended workarounds.

    Transit ACLs
    The following access list is specifically designed to block attack
    traffic. Note that the attack traffic can include spoofed source
    addresses. This access list should be applied to all interfaces of the
    device, both entering and leaving your network, and should include
    topology-specific filters. This could include filtering routing protocol
    traffic, management protocols, and traffic destined for the internal
    network. Protocol 103 is Protocol Independent Multicast (PIM), which is a
    commonly deployed application in multicast networks. Interfaces with PIM
    enabled have not been found to be vulnerable to exploit traffic with
    protocol 103; PIM traffic may be permitted to those select devices.

    access-list 101 deny 53 any any
    access-list 101 deny 55 any any
    access-list 101 deny 77 any any
    access-list 101 deny 103 any any
    !--- insert any other previously applied ACL entries here
    !--- you must permit other protocols through to allow normal
    !--- traffic -- previously defined permit lists will work
    !--- or you may use the permit ip any any shown here
    access-list 101 permit ip any any

    Prior to deploying ACLs that filter transit traffic, a classification ACL
    can be used to help identify required permit statements. A classification
    ACL is an ACL that permits a series of protocols. Displaying access-list
    entry hit counters helps determine required protocols: entries with zero
    packets counted are likely not required. Classification access-lists are
    detailed in the link below for infrastructure access-lists.

    Receive ACLs
    For distributed platforms, receive path access lists may be an option
    starting in Cisco IOS Software Versions 12.0(21)S2 for the c12000 and
    12.0(24)S for the c7500. The receive access lists protect the device from
    harmful traffic before the traffic can impact the route processor. Receive
    path ACLs are considered 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 CPU load is distributed to
    the line card processors and helps mitigate load on the main route
    processor. The white paper entitled "GSR: Receive Access Control Lists"
    will help you identify and allow legitimate traffic to your device and
    deny all unwanted packets:
    <http://www.cisco.com/warp/public/707/racl.html>
    http://www.cisco.com/warp/public/707/racl.html

    Infrastructure ACLs
    Although it is often difficult to block traffic transiting your network,
    it is possible to identify traffic that should never be allowed to target
    your infrastructure devices and block that traffic at the border of your
    network. Infrastructure ACLs are considered 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
    white paper entitled "Protecting Your Core: Infrastructure Protection
    Access Control Lists" presents guidelines and recommended deployment
    techniques for infrastructure protection ACLs:
    <http://www.cisco.com/warp/public/707/iacl.html>
    http://www.cisco.com/warp/public/707/iacl.html

    ADDITIONAL INFORMATION

    The information has been provided by <mailto:psirt@cisco.com> Cisco
    Product Security.

    ========================================

    This bulletin is sent to members of the SecuriTeam mailing list.
    To unsubscribe from the list, send mail with an empty subject line and body to: list-unsubscribe@securiteam.com
    In order to subscribe to the mailing list, simply forward this email to: list-subscribe@securiteam.com

    ====================
    ====================

    DISCLAIMER:
    The information in this bulletin is provided "AS IS" without warranty of any kind.
    In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages.

  • Next message: SecuriTeam: "[UNIX] Web Calendar Directory Traversal"

    Relevant Pages