SkipNavigation
Home | FAQ | Contact | Privacy Policy
US-CERT
American Flag
  Vulnerability
Notes
Database

Search Vulnerability Notes

Vulnerability Notes Help Information


 
 View Notes By
  Name

ID Number

CVE Name

Date Public

Date Published

Date Updated

Severity Metric
 Other Documents
  Technical Alerts

Technical Bulletins

Alerts

Security Tips
 

Vulnerability Note VU#222750

TCP/IP implementations do not adequately validate ICMP error messages

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.

I. Description

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: 


4.2.3.9  ICMP Messages

            TCP MUST act on an ICMP error message passed up from the IP
            layer, directing it to the connection that created the
            error.  The necessary demultiplexing information can be
            found in the IP header contained within the ICMP message.

            o    Source Quench

                 TCP MUST react to a Source Quench by slowing
                 transmission on the connection.  The RECOMMENDED
                 procedure is for a Source Quench to trigger a "slow
                 start," as if a retransmission timeout had occurred.

            o    Destination Unreachable -- codes 0, 1, 5

                 Since these Unreachable messages indicate soft error
                 conditions, TCP MUST NOT abort the connection, and it
                 SHOULD make the information available to the
                 application.

                 DISCUSSION:
                      TCP could report the soft error condition directly
                      to the application layer with an upcall to the
                      ERROR_REPORT routine, or it could merely note the
                      message and report it to the application only when
                      and if the TCP connection times out.

            o    Destination Unreachable -- codes 2-4

                 These are hard error conditions, so TCP SHOULD abort
                 the connection.

            o    Time Exceeded -- codes 0, 1

                 This should be handled the same way as Destination
                 Unreachable codes 0, 1, 5 (see above).

            o    Parameter Problem

                 This should be handled the same way as Destination
                 Unreachable codes 0, 1, 5 (see above).

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.

II. 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.

III. Solution

Upgrade or apply a patch

Upgrade 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.

Systems Affected

VendorStatusDate Updated
3ComUnknown7-Feb-2005
AlcatelVulnerable8-Sep-2005
Allied Telesyn InternationalVulnerable29-Apr-2005
Apple Computer, Inc.Unknown12-Apr-2005
AT&TUnknown7-Feb-2005
AvayaUnknown7-Feb-2005
Avici Systems Inc.Unknown7-Feb-2005
BorderwareUnknown7-Feb-2005
Charlotte's Web NetworksUnknown8-Sep-2005
Check PointNot Vulnerable12-Apr-2005
Chiaro NetworksUnknown7-Feb-2005
Cisco Systems, Inc.Vulnerable12-Apr-2005
ClavisterNot Vulnerable12-Apr-2005
Computer AssociatesUnknown7-Feb-2005
Cray Inc.Unknown7-Feb-2005
Cyber GuardNot Vulnerable12-Apr-2005
Data ConnectionUnknown7-Feb-2005
Debian LinuxUnknown7-Feb-2005
DlinkUnknown7-Feb-2005
EMC CorporationUnknown7-Feb-2005
EngardeUnknown7-Feb-2005
Enterasys NetworksNot Vulnerable15-Jun-2005
eSoftUnknown7-Feb-2005
Extreme NetworksVulnerable21-Apr-2005
F5 Networks, Inc.Vulnerable3-May-2005
Fedora ProjectNot Vulnerable12-Apr-2005
FortinetNot Vulnerable21-Apr-2005
Foundry Networks Inc.Not Vulnerable12-Apr-2005
FreeBSD, Inc.Unknown7-Feb-2005
FujitsuNot Vulnerable8-Sep-2005
GTAUnknown7-Feb-2005
Hewlett-Packard CompanyVulnerable8-Sep-2005
HitachiVulnerable8-Sep-2005
HyperchipUnknown7-Feb-2005
IBM CorporationVulnerable12-Apr-2005
ImmunixUnknown7-Feb-2005
Ingrian Networks, Inc.Unknown7-Feb-2005
IntelUnknown7-Feb-2005
IntotoNot Vulnerable7-Feb-2005
IP FilterUnknown7-Feb-2005
Juniper Networks, Inc.Vulnerable5-May-2005
LachmanUnknown7-Feb-2005
LinksysUnknown7-Feb-2005
Lucent TechnologiesUnknown7-Feb-2005
LuminousUnknown7-Feb-2005
Mandriva, Inc.Unknown7-Feb-2005
Mandriva, Inc.Unknown7-Feb-2005
Microsoft CorporationVulnerable29-Apr-2005
MontaVista Software, Inc.Unknown7-Feb-2005
Multi-Tech Systems Inc.Unknown7-Feb-2005
MultinetUnknown7-Feb-2005
NEC CorporationNot Vulnerable8-Sep-2005
NetBSDUnknown7-Feb-2005
NetfilterVulnerable29-Apr-2005
NetscreenNot Vulnerable12-Apr-2005
Network ApplianceVulnerable11-Apr-2005
Network AssociatesUnknown12-Apr-2005
NextHopUnknown21-Apr-2005
NokiaUnknown7-Feb-2005
Nortel Networks, Inc.Vulnerable8-Sep-2005
Novell, Inc.Unknown7-Feb-2005
OpenBSDVulnerable21-Apr-2005
Openwall GNU/*/LinuxUnknown7-Feb-2005
Polycom Inc.Unknown8-Sep-2005
Red Hat, Inc.Vulnerable12-Apr-2005
Redback Networks Inc.Vulnerable12-Apr-2005
Riverstone NetworksUnknown7-Feb-2005
SCOVulnerable12-Apr-2005
Secure Computing CorporationNot Vulnerable12-Apr-2005
SecureWorksNot Vulnerable3-May-2005
SecureWorxUnknown3-May-2005
Sequent Computer Systems, Inc.Unknown7-Feb-2005
SGIUnknown7-Feb-2005
Sony CorporationUnknown7-Feb-2005
StonesoftNot Vulnerable12-Apr-2005
Sun Microsystems, Inc.Vulnerable12-Apr-2005
SUSE LinuxUnknown7-Feb-2005
Symantec CorporationVulnerable3-May-2005
Tech MatrixNot Vulnerable29-Apr-2005
TurboLinuxUnknown7-Feb-2005
UnisysUnknown7-Feb-2005
WatchGuardVulnerable11-Apr-2005
Wind River Systems, Inc.Vulnerable12-Apr-2005
YamahaNot Vulnerable29-Apr-2005
ZyXELUnknown7-Feb-2005

References

http://www.kb.cert.org/vuls/id/415294
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

Credit

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 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.

This document was written by Art Manion.

Other Information

Date Public04/12/2005
Date First Published04/13/2005 12:58:13 PM
Date Last Updated04/22/2008
CERT Advisory 
CVE Name 
US-CERT Technical Alerts 
Metric12.48
Document Revision90

If you have feedback, comments, or additional information about this vulnerability, please send us email.
 

 
Page Corner Image
Copyright 2005 Carnegie Mellon University
Disclaimers and copyright information
Get Adobe Reader Get Adobe Reader