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.




Network Security Exploits-HackingTools
[Top] [All Lists]

[NEWS] Crafted TCP Packet Can Cause DoS

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>
  • [NEWS] Crafted TCP Packet Can Cause DoS, SecuriTeam <=