{"vuid":"VU#222750","idnumber":"222750","name":"TCP/IP implementations do not adequately validate ICMP error messages","keywords":["Source Quench","SOURCE_QUENCH","ICMP","TCP","BGP","MTU","PMTU","MSS TCP","PathMTU","Hard RST","tcpsecure","anonsec","IPR","ms06-oct"],"overview":"Multiple TCP/IP implementations do not adequately validate ICMP error messages. A remote attacker could cause TCP connections to drop or be degraded using spoofed ICMP error messages.","clean_desc":"A number of widely accepted Internet standards describe different aspects of the relationships between the Internet Control Message Protocol (ICMP) and Transmission Control Protocol (TCP). In particular, RFC 1122 explains how TCP should respond to ICMP messages: [<pre>\n4.2.3.9  ICMP Messages TCP MUST act on an ICMP error message passed up from the IP\n            layer, directing it to the connection that created the\n            error. The necessary demultiplexing information can be\n            found in the IP header contained within the ICMP message. o    Source Quench TCP MUST react to a Source Quench by slowing\n                 transmission on the connection. The RECOMMENDED\n                 procedure is for a Source Quench to trigger a \"slow\n                 start,\" as if a retransmission timeout had occurred. o    Destination Unreachable -- codes 0, 1, 5 Since these Unreachable messages indicate soft error\n                 conditions, TCP MUST NOT abort the connection, and it\n                 SHOULD make the information available to the\n                 application. DISCUSSION: TCP could report the soft error condition directly\n                      to the application layer with an upcall to the\n                      ERROR_REPORT routine, or it could merely note the\n                      message and report it to the application only when\n                      and if the TCP connection times out. o    Destination Unreachable -- codes 2-4 These are hard error conditions, so TCP SHOULD abort\n                 the connection. o    Time Exceeded -- codes 0, 1 This should be handled the same way as Destination\n                 Unreachable codes 0, 1, 5 (see above). o    Parameter Problem This should be handled the same way as Destination\n                 Unreachable codes 0, 1, 5 (see above). </pre> An ICMP message contains the IP header and the first 8 bytes of the transport layer (TCP) segment that caused the error condition (this covers IP and TCP header information). In order to match an ICMP message to a TCP connection, TCP stack implementations generally match the source and destination TCP port and IP address four-tuple from the data returned in the ICMP message. An attacker who knows or can guess this four-tuple can create spoofed ICMP messages. By setting ICMP types and codes to indicate hard or soft error conditions, the attacker may be able to cause valid TCP connections to be reset or degraded. An attacker may also be able to take advantage of path MTU discovery functionality by spoofing ICMP type 3 (Destination Unreachable) code 4 (Fragmentation Needed but Don't Fragment Bit Set) messages and lowering the MTU for a connection (this is described in section 8 of RFC 1191). Note that any protocols that use path MTU discovery and state-based transport layer protocols other than TCP could also be affected. Further details about this vulnerability are available in an IETF Internet Draft titled \"ICMP attacks against TCP\" authored by Fernando Gont.","impact":"A remote attacker could cause TCP connections to drop or be degraded using spoofed ICMP error messages. Applications that depend on on long-lived, low latency, or high throughput TCP connections may not function correctly on a degraded TCP connection. In order to spoof an ICMP message, an attacker would need to know or guess the source and destination TCP port and IP address four-tuple. The Border Gateway Protocol (BGP) is of paticular concern since it relies on long-lived TCP connections (VU#415294), uses well-known source and destination ports, provides critical network and Internet routing information, and may require a non-trivial period of time to recover from a sustained attack.","resolution":"Upgrade or apply a patch\nUpgrade or apply a patch according to vendor instructions. Note that changes made by upgrades or patches may not completely defend against spoofed ICMP attacks. Consult vendor documentation for information on changes to ICMP message handling. Consider the general and attack-specific countermeasures discussed in the Gont I-D. Some of the countermesures include validating TCP sequence and acknowledgement numbers contained in ICMP messages, improving TCP ephemeral port number randomization, changing the response to or ignoring certain ICMP messages, and delaying connection resets. Note that different countermeasures have different constraints and may negatively impact TCP operations. Filter ICMP messages Filter ICMP messages based on type and code at network borders. Allow only ICMP messages that are necessary for proper operation. IPsec and TCP MD5 Note that TCP MD5 does not provide authentication for ICMP messages. Current IPsec specifications do not define how IPsec implementations should handle ICMP messages destined for authenticated TCP connections.","workarounds":"","sysaffected":"","thanks":"Information about the security risks of ICMP messages has been known for some time (RFC 1191 was published in 1990). More recent work by Fernando Gont (Universidad Tecnológica Nacional - Facultad Regional Haedo) describes different types of ICMP attacks against TCP and proposes a number of defense techniques. Gont's research\n is documented in an IETF Internet Draft titled \"ICMP attacks against TCP\" (revision 3 as of this writing). Jonathan Looney researched and reported a specific ICMP attack that affects TCP connections on Microsoft Windows systems.","author":"This document was written by Art Manion.","public":["http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html","http://tools.ietf.org/wg/opsec/draft-gont-opsec-icmp-filtering-00.txt","http://www.ietf.org/rfc/rfc792.txt","http://www.ietf.org/rfc/rfc1122.txt","http://www.ietf.org/rfc/rfc1191.txt","http://www.ietf.org/rfc/rfc1323.txt","http://www.ietf.org/rfc/rfc2385.txt","http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf","http://jvn.jp/niscc/532967/index.html","http://xforce.iss.net/xforce/xfdb/17170","http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0790","http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0791","http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-1060","http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0065","http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0066","http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0067","http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-0068","http://www.securiteam.com/securitynews/5AP0D2A35U.html","http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-02.txt","http://www.ietf.org/ietf/03mar/plpmtud.txt","http://www.psc.edu/~mathis/MTU/","http://www.cymru.com/Documents/icmp-messages.html","http://secunia.com/advisories/14904/","http://securitytracker.com/alerts/2005/Apr/1013686.html"],"cveids":[""],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2004-08-12T15:12:23Z","publicdate":"2005-04-12T00:00:00Z","datefirstpublished":"2005-04-12T21:20:32Z","dateupdated":"2008-04-22T22:34:50Z","revision":90,"vrda_d1_directreport":"0","vrda_d1_population":"4","vrda_d1_impact":"3","cam_widelyknown":"12","cam_exploitation":"0","cam_internetinfrastructure":"20","cam_population":"20","cam_impact":"5","cam_easeofexploitation":"13","cam_attackeraccessrequired":"16","cam_scorecurrent":"12.48","cam_scorecurrentwidelyknown":"15.6","cam_scorecurrentwidelyknownexploited":"23.4","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":12.48,"vulnote":null}