Ethical Hacking Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package. | Computer Forensics Training at InfoSec Institute Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors. |

| Subject: | [NEWS] Crafted TCP Packet Can Cause DoS |
|---|---|
| Date: | 24 Jan 2007 19:54:24 +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 The SecuriTeam alerts list - Free, Accurate, Independent. Get your security news from a reliable source. http://www.securiteam.com/mailinglist.html - - - - - - - - - Crafted TCP Packet Can Cause DoS ------------------------------------------------------------------------ SUMMARY The Cisco IOS Transmission Control Protocol (TCP) listener in certain versions of Cisco IOS software is vulnerable to a remotely-exploitable memory leak that may lead to a denial of service condition. This vulnerability only applies to traffic destined to the Cisco IOS device. Traffic transiting the Cisco IOS device will not trigger this vulnerability. Cisco has made free software available to address this vulnerability for affected customers. This issue is documented as Cisco bug ID <http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCek37177> CSCek37177 ( registered customers only) . There are workarounds available to mitigate the effects of the vulnerability. DETAILS Affected Products: Vulnerable Products This issue affects all Cisco devices running Cisco IOS software. To be affected, devices must be configured to process Internet Protocol version 4 (IPv4) packets and receive TCP packets. Devices which run only Internet Protocol version 6 (IPv6) are not affected. This vulnerability is present in all unfixed versions of Cisco IOS software, including versions 9.x, 10.x, 11.x and 12.x. 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 Cisco IOS release 12.2(14)S16 with an installed image name of C7200-IS-M: Cisco Internetwork Operating System Software IOS (tm) 7200 Software (C7200-IS-M), Version 12.2(14)S16, RELEASE SOFTWARE (fc1) The release train label is "12.2". The next example shows a product running IOS release 12.3(7)T12 with an image name of C7200-IK9S-M: Cisco IOS Software, 7200 Software (C7200-IK9S-M), Version 12.3(7)T12, RELEASE SOFTWARE (fc1) Additional information about Cisco IOS Banners is available at: <http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper09186a008018305e.shtml#3> http://www.cisco.com/en/US/products/sw/iosswrel/ps1828/products_white_paper09186a008018305e.shtml#3 Products Confirmed Not Vulnerable Cisco products that do not run IOS are unaffected by this vulnerability. Cisco IOS-XR is not affected. No other Cisco products are currently known to be affected by this vulnerability. Details TCP is the transport layer protocol designed to provide connection-oriented, reliable delivery of a data stream. To accomplish this, TCP uses a mixture of flags to indicate state and sequence numbers to identify the order in which the packets are to be reassembled. TCP also provides a number, called an acknowledgment number, that is used to indicate the sequence number of the next packet expected. The full specification of the TCP protocol can be found at <http://www.ietf.org/rfc/rfc0793.txt> http://www.ietf.org/rfc/rfc0793.txt. Cisco IOS devices that are configured to receive TCP packets are exposed to this issue. This Advisory does not apply to traffic that is transiting the device. Certain crafted packets destined to an IPv4 address assigned to a physical or virtual interface on a Cisco IOS device may cause the device to leak a small amount of memory. Over time, such a memory leak may lead to memory exhaustion and potentially degraded service. Although this is an issue with TCP, it is not required to complete the TCP 3-way handshake in order for the memory leak to be triggered. Therefore, TCP packets with a spoofed source address may trigger the leak. The following document contains additional information on how to identify if your router is suffering from a memory leak in Processor memory: <http://www.cisco.com/warp/public/63/mallocfail.shtml#tshoot2> http://www.cisco.com/warp/public/63/mallocfail.shtml#tshoot2 Impact: Successful exploitation of the vulnerability may result in a small amount of processor memory to leak, which may lead to degraded service. This issue will not resolve over time, and will require a device reset to recover the leaked memory. This vulnerability only applies to traffic destined to the Cisco IOS device. Traffic transiting the device will not trigger this issue. Workarounds: Additional mitigations that can be deployed on Cisco devices within the network are available in the Cisco Applied Intelligence companion document for this advisory: <http://www.cisco.com/warp/public/707/cisco-air-20070124-crafted-tcp.shtml> http://www.cisco.com/warp/public/707/cisco-air-20070124-crafted-tcp.shtml Note: Configuring VTY access-class filters is not an effective mitigation strategy for this vulnerability. Infrastructure ACLs (iACL) 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. 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 ACL 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. A sample access list for devices running Cisco IOS is below: !--- Permit TCP services from trust hosts destined !--- to infrastructure addresses. access-list 150 permit tcp TRUSTED_HOSTS MASK INFRASTRUCTURE_ADDRESSES MASK !--- Deny TCP packets from all other sources destined to infrastructure addresses. access-list 150 deny tcp any INFRASTRUCTURE_ADDRESSES MASK !--- Permit all other traffic to transit the device. access-list 150 permit IP any any interface serial 2/0 ip access-group 150 in 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/warp/public/707/iacl.html> http://www.cisco.com/warp/public/707/iacl.html Receive ACLs (rACL) For distributed platforms, Receive ACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 (GSR), 12.0(24)S for the 7500, and 12.0(31)S for the 10720. The Receive ACL protects the device from harmful traffic before the traffic can impact the route processor. Receive ACLs are designed to only protect the device on which it is configured. On the 12000, transit traffic is never affected by a receive ACL. Because of this, the destination IP address "any" used in the example ACL entries below only refer to the router's own physical or virtual IP addresses. On the 7500 and 10720, transit traffic with IP options set will be subject to the Receive ACL and permitted or denied accordingly. Receive 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 "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 The following is the receive path ACL written to permit this type of traffic from trusted hosts: !--- Permit tcp services from trusted hosts allowed to the RP. access-list 151 permit tcp TRUSTED_ADDRESSES MASK any !--- Deny tcp services from all other sources to the RP. access-list 151 deny tcp any any !--- Permit all other traffic to the RP. access-list 151 permit ip any any !--- Apply this access list to the 'receive' path. ip receive access-list 151 Control Plane Policing (CoPP) The Control Plane Policing (CoPP) feature may be used to mitigate this vulnerability. In the following example, only TCP traffic from trusted hosts and with 'receive' destination IP addresses is permitted to reach the route processor (RP). All other 'transit' IP traffic is unaffected. It should be noted that dropping traffic from unknown or untrusted IP addresses may affect hosts with dynamically assigned IP addresses from connecting to the Cisco IOS device. access-list 152 deny tcp TRUSTED_ADDRESSES MASK any access-list 152 permit tcp any any access-list 152 deny ip any any ! class-map match-all permit-tcp-class match access-group 152 ! ! policy-map permit-tcp-policy class permit-tcp-class drop ! control-plane service-policy input permit-tcp-policy In the above CoPP example, the ACL entries that match the 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 are not affected by the policy-map drop function. Please note that in the 12.2S and 12.0S Cisco IOS trains the policy-map syntax is different: policy-map permit-tcp-policy class class permit-tcp-class police 32000 1500 1500 conform-action drop exceed-action drop CoPP is available in Cisco IOS release trains 12.0S, 12.2SX, 12.2S, 12.3T, 12.4, and 12.4T. Additional information on the configuration and use of the CoPP feature can be found at the following URL: <http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_white_paper09186a0080211f39.shtml> http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_white_paper09186a0080211f39.shtml Anti-spoofing The Unicast Reverse Path Forwarding (Unicast RPF or uRPF) feature helps to mitigate problems that are caused by spoofed IP source addresses. It is available on Cisco routers and firewalls. For further details, please refer to: <http://www.cisco.com/en/US/partner/products/ps6441/products_command_reference_chapter09186a00804ae49f.html#wp1229984> http://www.cisco.com/en/US/partner/products/ps6441/products_command_reference_chapter09186a00804ae49f.html#wp1229984 By enabling Unicast Reverse Path Forwarding (uRPF), all spoofed packets will be dropped at the first device. To enable uRPF, use the following commands. router(config)# ip cef router(config)# interface interface # router(config-if)# ip verify unicast source reachable-via rx BGP and BTSH/GTSM Depending on your release of software, it may be possible to protect your BGP sessions from this memory leak. With the introduction of CSCee73956 ( registered customers only) , Cisco IOS has improved support for BTSH (BGP TTL Security Hack) to reduce, if not eliminate a risk of a memory leak due to this vulnerability. This functionality is also known as GTSM (Generalized TTL Security Mechanism) and documented in RFC 3682. This section refers to GTSM as applied to eBGP sessions only. Releases of Cisco IOS that contain CSCee73956 are protected from this attack against the BGP port (TCP port 179) only. Other ports should be protected accordingly. BTSH is not supported for iBGP sessions. BTSH was first introduced in Cisco IOS in 12.0(27)S, 12.3(7)T and 12.2(25)S. Note that the BTSH feature prior to CSCee73956 will not protect against this vulnerability. For more information on BTSH, please see: <http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_7/gt_btsh.htm> http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123newft/123t/123t_7/gt_btsh.htm ADDITIONAL INFORMATION sThe information has been provided by <mailto:psirt@cisco.com> Cisco Systems Product Security Incident Response Team. The original article can be found at: <http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-tcp.shtml> http://www.cisco.com/warp/public/707/cisco-sa-20070124-crafted-tcp.shtml ======================================== 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.
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | [NEWS] OBEX Push Bluetooth DoS, SecuriTeam |
|---|---|
| Next by Date: | [NEWS] IPv6 Routing Header Vulnerability, SecuriTeam |
| Previous by Thread: | [NEWS] OBEX Push Bluetooth DoS, SecuriTeam |
| Next by Thread: | [NEWS] IPv6 Routing Header Vulnerability, SecuriTeam |
| Indexes: | [Date] [Thread] [Top] [All Lists] |