copyright | disclaimer | privacy | contact

HOME   About AusCERT   Membership   Contact Us   PKI Services   Training   Publications   Sec. Bulletins   Conferences   News & Media   Services   Web Log   Site Map   Site Help   Member login Login »  Become a member »   Home » Security Bul... » By Operating... » Windows (all) » Windows ME » ESB-2005.0575 -- UNIRAS ALERT - 12/05 -- NISCC Vulne...   ESB-2005.0575 -- UNIRAS ALERT - 12/05 -- NISCC Vulnerability Advisory ICMP - 532967 Date: 20 July 2005 References: ESB-2005.0305  ESB-2005.0312  ESB-2005.0356  ESB-2005.0363  ESB-2005.0409  ESB-2005.0570  ESB-2005.0644  ESB-2006.0004  AA-2006.0080   Click here for printable version -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 =========================================================================== AUSCERT External Security Bulletin Redistribution ESB-2005.0575 -- UNIRAS ALERT - 12/05 NISCC Vulnerability Advisory ICMP - 532967 20 July 2005 =========================================================================== AusCERT Security Bulletin Summary --------------------------------- Publisher: UNIRAS Impact: Denial of Service Access: Remote/Unauthenticated CVE Names: CAN-2004-1060 CAN-2004-0791 CAN-2004-0790 Ref: ESB-2005.0305 ESB-2005.0312 ESB-2005.0363 ESB-2005.0356 ESB-2005.0409 ESB-2005.0570 Original Bulletin: http://www.uniras.gov.uk/niscc/docs/al-20050412-00308.html - --------------------------BEGIN INCLUDED TEXT-------------------- - ----------------------------------------------------------------------------------- UNIRAS (UK Govt CERT) ALERT - 12/05 dated 12.04.05 Time: 13:00 UNIRAS is part of NISCC (National Infrastructure Security Co-ordination Centre) - ----------------------------------------------------------------------------------- UNIRAS material is also available from its website at www.uniras.gov.uk and Information about NISCC is available from www.niscc.gov.uk - ----------------------------------------------------------------------------------- Title ===== NISCC Vulnerability Advisory ICMP - 532967 Detail ====== NISCC Vulnerability Advisory 532967/NISCC/ICMP Vulnerability Issues in ICMP packets with TCP payloads Version Information - -------------------- Advisory Reference 532967/NISCC/ICMP Release Date 12 April 2005 Last Revision 12 April 2005 Version Number 1.0 What is Affected? - ------------------ The vulnerabilities described in this advisory affect the TCP (Transmission Control Protocol) by using Internet Control Message Protocol (ICMP) messages that comply with the Internet Engineering Task Force's (IETF's) Requests For Comments (RFCs) for ICMP, including RFC 792 "Internet Control Message Protocol: DARPA Internet Program Protocol Specification" (for IP Version 4), RFC 1122, "Requirements for Internet Hosts -- Communication Layers" and potentially RFC 2463 "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification" (for IP Version 6). The original TCP specification is provided in RFC 793. ICMP is the control protocol for IP (Internet Protocol), a core network protocol used in the majority of networked computer systems today. Most vendors include support for this protocol in their products and may be impacted to varying degrees. Furthermore any network service or application that relies on a long-lived TCP connection will also be impacted if the host processes ICMP messages in accordance with RFC 1122. For the Source Quench attack the severity will depend on the throughput of the TCP connection; the application may well become unusable. Severity - --------- The impact of the ICMP TCP reset vulnerability (called "the TCP blind connection-reset vulnerability" in this advisory) varies by vendor and application, but in some deployment scenarios it is likely to be rated medium to high. Please see the 'Vendor Information' section below for further information. Alternatively contact your vendor for product specific information. If exploited, the TCP blind connection-reset vulnerability could allow an attacker to create a denial-of-service condition against existing TCP connections, resulting in premature session termination. The resulting session termination will affect the application layer, the nature and severity of the effects being dependent on the application layer protocol. The primary dependency is on the tolerance of the network service or application to the loss of a TCP connection. The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability. BGP relies on a persistent TCP connection between BGP peers; resetting the connection can result in medium term unavailability due to the need to rebuild routing tables and route flapping. Route flapping may result in route dampening (suppression) if the route flaps occur frequently within a short time interval. The overall impact on BGP is likely to be low to moderate based on the likelihood of successful attack, but could be high if an ICMP implementation does not perform any checks on the ICMP payload. If an access control list is applied at routers to block packets of ICMP Type 3 codes 2, 3 and 4 then the impact will be low as this measure will successfully mitigate the vulnerability. Anti-spoofing measures can also be of benefit if the attacker spoofs the IP address from where the ICMP packet is sent. Anti-spoofing measures include access control lists to block non-routable IP addresses (see RFCs 1918 and 3330) and Unicast Reverse Path Forwarding (URPF) that checks the consistency of the source IP address with the interface on which the packets are received. See NISCC Technical Note 06/02 "Response to Distributed Denial-of-Service (DDoS) Attacks" for further details. There is a potential impact on other application protocols such as DNS (Domain Name System) and SSL (Secure Sockets Layer) in the case of zone transfers and ecommerce transactions respectively, but the sessions can be restarted without medium term unavailability problems. In the case of DNS the TCP connections are short lived, so the chance of the vulnerability being exploited is lower than for long lived TCP connections. In the case of SSL it may be difficult to guess the source IP address because it could be dynamically allocated home user address (in the case of Internet banking). The severity of the related issue of slowing down routers that use Path MTU discovery is also likely to be moderate to high in some vendors' products because RFC 792 and RFC 1191 ("Path MTU discovery") do not specify checking of sequence numbers. The severity of the spoofing of ICMP Source Quench packets is likely to be moderate to low because the support of routers for Source Quench as a means of congestion control has been deprecated for ten years. RFC 1812 section 5.3.6 states: "As described in Section [4.3.3.3], this document recommends that a router SHOULD NOT send a Source Quench to the sender of the packet that it is discarding. ICMP Source Quench is a very weak mechanism, so it is not necessary for a router to send it, and host software should not use it exclusively as an indicator of congestion." On the other hand, RFC 1122 section 4.2.3.9 states that "TCP MUST react to a Source Quench by slowing transmission on the connection", a statement honoured in a number of TCP implementations. To mitigate Source Quench attacks using spoofed IP addresses in the payload, ICMP Source Quench (ICMP Type 4) messages should not be allowed through routers or through firewalls at the organisational perimeter. It is reasonable to allow routers to block Source Quench packets if their use is deprecated. Summary - -------- The first issue described in this advisory is the practicability of resetting an established TCP connection by sending suitable ICMP packets that simulate a hard error condition in an existing TCP connection. Hard error conditions are defined in RFC 1122 section 4.2.3.9 and include a number of common ICMP types. An ICMP error packet records the IP header of the packet causing the error as well as the first 64 bits of the TCP header, which consists of the source and destination ports and the sequence number. Many ICMP implementations only check the IP addresses and TCP ports at either end of the connection; they do not check whether the sequence number of the packet is within an acceptable range (see 'Details' section below for characterisation of this range). It is thus possible in some implementations for an attacker to reset an existing TCP connection by sending a suitably crafted ICMP packet with the correct IP addresses and TCP ports. The target of these denial-of-service attacks is any TCP connection, especially one for which the source port can be identified or guessed. Moreover any application protocol which relies on long term TCP connections and for which the source and destination IP addresses and TCP ports are known or can be easily guessed will be vulnerable to denial-of-service attacks. A related, subsidiary issue is the potential ability to slow down traffic through hosts that use Path MTU discovery (defined in RFC 1191) by sending forged ICMP Type 3 Code 4 ("Fragmentation Needed and Don't Fragment was Set") packets that report a (false) low "next-hop MTU" to a host using the Path MTU discovery mechanism. The third issue described in this advisory is the practicability of slowing the traffic between two hosts by sending ICMP Source Quench packets to an endpoint of the session. The technique used is to send a Source Quench packet including the details of the TCP connection to be targeted. According to RFC 1122, the Source Quench packet will limit the rate of the TCP connection. It is possible to apply the TCP blind connection-reset vulnerability to ICMP Version 6 packets (the control protocol of IP Version 6) by equating hard errors to ICMPv6 Type 1 (Destination Unreachable) codes 1 (communication with destination administratively prohibited) and 4 (port unreachable). The Path MTU discovery attack could be affected by sending an ICMPv6 Type 2 code 0 ("Packet Too Big") packet, which does not describe a hard error but is used to determine end to end path MTU. Source quench is not defined in RFC 2463 for ICMPv6. Since IP Version 6 was not defined when RFC 1122 was written, the discussion in this advisory will concentrate on IP Version 4. Further details of how the attacks apply to IP Version 6 is available in Fernando Gont's Internet Draft "ICMP attacks against TCP". Details - -------- 532967/NISCC/ICMP/1 CVE number: CAN-2004-0790 RFC 1122 section 4.2.3.9 refers to some ICMP message types as representing hard errors. These message types are ICMP Type 3 (Destination Unreachable) codes 2 (Protocol Unreachable), 3 (Port Unreachable) and 4 (Fragmentation Needed and Don't Fragment was Set). For hard errors, according to RFC 1122 the TCP implementation should abort the connection. Thus by sending an ICMP Type 3, code 2, 3 or 4 with the IP header and the first 64 bits of the header of a TCP as its payload (the source and destination TCP ports and the sequence number), the receiving TCP implementation would reset the existing connection if it did not check that the sequence number was as expected. It should be noted that the current RFCs do not recommend that TCP implementations check the sequence number. In section 5.1 of his Internet Draft "ICMP attacks against TCP" Fernando Gont states: "TCP SHOULD check that the sequence number in the TCP header contained in the payload of the ICMP error message is within the range SND.UNA <= SEG.SEQ < SND.NXT. This means that the sequence number should be within the range of the data already sent but not yet acknowledged. If an ICMP error message doesn't pass this check, it SHOULD be discarded." Here SND.UNA is the oldest unacknowledged sequence number, SEG.SEQ is the sequence number contained in the payload of the ICMP error message, and SND.NXT is the next sequence number to be sent. There is a dependency on the TCP window size as without scaling (see RFC 1323) the range of unacknowledged sequence numbers can be in the range SND.UNA to SND.NXT-1. 532967/NISCC/ICMP/2 CVE number: CAN-2004-1060 In the case where a host complies with RFC 1191 ("Path MTU Discovery"), it is possible to use the blind connection-reset attack with a ICMP Type 3 Code 4 packet and the addition of the "next-hop MTU" field in the ICMP header set to a value of 68 (octets) to slow down the transmission rate for traffic from the host. NISCC/532967/ICMP/3 CVE number: CAN-2004-0791 RFC 1122 section 4.2.3.9 states "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." Thus by sending an ICMP Type 4 (Source Quench) packet to a host with the IP header and the first 64 bits of the header of a TCP as its payload, the receiving TCP implementation would rate limit the existing connection if it did not check that the sequence number was expected. As noted above, the current RFCs do not recommend that TCP implementations check the sequence number. Mitigation - ----------- The main impact of the TCP blind connection-reset vulnerability is on applications that are intolerant of loss of a TCP session, such as BGP. In this case applying an access control list to block ICMP Type 3 code 2, 3 and 4 packets to BGP routers will be an effective mitigation, as will the use of anti-spoofing measures in the case that the ICMP packet inducing the reset is sent from a spoofed IP address. In the case of hosts which use Path MTU discovery, the only mitigation is to disable the use of the Path MTU discovery mechanism until the vendor provides a security patch. The Source Quench vulnerability can be mitigated by applying an access control list blocking ICMP Type 4 packets on routers and by blocking ICMP Type 4 packets to corporate networks at the organisational boundary. Again, anti-spoofing measures such as URPF and access control lists blocking private, non-routable IP addresses at routers will also provide some protection if the source IP address of the ICMP packet is spoofed. Solution - --------- General solutions to the vulnerabilities are described in section 5 of Fernando Gont's Internet Draft "ICMP attacks against TCP" (see http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-03.txt). These solutions include: - - - Checking that the TCP sequence number is within the range of the data already sent but not yet acknowledged - - - (On routers) checking that the TCP acknowledgement number is in the range of the last sequence number acknowledged to the next sequence number expected - - - Randomising source (ephemeral client) port numbers (making the port number more difficult to guess) - - - Providing authentication mechanisms for ICMP messages to ensure that an ICMP message is processed only if it is correctly authenticated - - - Ingress and egress filtering on the IP addresses and TCP ports in the payload of ICMP packets - - - Changing the behaviour of a TCP implementation when the ICMP message is not expected to cause a soft rather than a hard error - - - Delaying the TCP connection reset until an ICMP error message indicating a hard error has been received a specified number of times - - - To protect against resets against Path MTU Discovery, delay the handling of a ICMP Type 3 Code 4 ("packet too big" error) packets in the case where the Path MTU has already been negotiated, i.e. where larger packets sizes have been already sent and acknowledged - - - Changing the handling of ICMP hard error messages for connections in synchronized states to ignore the messages during the life of a connection or to treat them as soft errors - - - Ignoring Source Quench ICMP packets Please refer to the 'Vendor Information' section of this advisory for implementation specific remediation. Credits - -------- This issue was discovered by Fernando Gont (UTN/FRH) and is the subject of an Internet draft by the same author; "ICMP attacks against TCP" (see http://www.ietf.org/internet-drafts/draft-gont-tcpm-icmp-attacks-03.txt). The latest version of the Internet Draft can be obtained from http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html. NISCC wishes to thank Fernando Gont for bringing this vulnerability to our attention and for agreeing to allow NISCC to co-ordinate the disclosure of this issue. NISCC also wishes to thanks Fernando for his comments on this advisory. Vendor Information - ------------------- A list of vendors affected by this vulnerability is not currently available. Please visit the web site (http://www.niscc.gov.uk/niscc/docs/re-20050412-00303.pdf?lang=en) in order to check for updates. What is NISCC? - --------------- For further information regarding the UK National Infrastructure Security Co-Ordination Centre, please visit the NISCC web site at: http://www.niscc.gov.uk. Reference to any specific commercial product, process or service by trade name, trademark manufacturer or otherwise, does not constitute or imply its endorsement, recommendation, or favouring by NISCC. The views and opinions of authors expressed within this notice shall not be used for advertising or product endorsement purposes. Neither shall NISCC accept responsibility for any errors or omissions contained within this advisory. In particular, they shall not be liable for any loss or damage whatsoever, arising from or in connection with the usage of information contained within this notice. C 2005 Crown Copyright <End of NISCC Vulnerability Advisory> - ----------------------------------------------------------------------------------- UNIRAS wishes to acknowledge the contributions of The NISCC Vulnerability Team for the information contained in this Briefing. - ----------------------------------------------------------------------------------- - --------------------------END INCLUDED TEXT-------------------- You have received this e-mail bulletin as a result of your organisation's registration with AusCERT. The mailing list you are subscribed to is maintained within your organisation, so if you do not wish to continue receiving these bulletins you should contact your local IT manager. If you do not know who that is, please send an email to auscert@auscert.org.au and we will forward your request to the appropriate person. NOTE: Third Party Rights This security bulletin is provided as a service to AusCERT's members. As AusCERT did not write the document quoted above, AusCERT has had no control over its content. The decision to follow or act on information or advice contained in this security bulletin is the responsibility of each user or organisation, and should be considered in accordance with your organisation's site policies and procedures. AusCERT takes no responsibility for consequences which may arise from following or acting on information or advice contained in this security bulletin. NOTE: This is only the original release of the security bulletin. It may not be updated when updates to the original are made. If downloading at a later date, it is recommended that the bulletin is retrieved directly from the author's website to ensure that the information is still current. Contact information for the authors of the original document is included in the Security Bulletin above. If you have any questions or need further information, please contact them directly. Previous advisories and external security bulletins can be retrieved from: http://www.auscert.org.au/render.html?cid=1980 If you believe that your computer system has been compromised or attacked in any way, we encourage you to let us know by completing the secure National IT Incident Reporting Form at: http://www.auscert.org.au/render.html?it=3192 =========================================================================== Australian Computer Emergency Response Team The University of Queensland Brisbane Qld 4072 Internet Email: auscert@auscert.org.au Facsimile: (07) 3365 7031 Telephone: (07) 3365 4417 (International: +61 7 3365 4417) AusCERT personnel answer during Queensland business hours which are GMT+10:00 (AEST). On call after hours for member emergencies only. =========================================================================== -----BEGIN PGP SIGNATURE----- Comment: http://www.auscert.org.au/render.html?it=1967 iQCVAwUBQt2qCyh9+71yA2DNAQJEDwP/Qm+xnJBs4JyJgyxw7i/Zuwh3U4tyq2Ud 4gM7EvZqY+4LKxY8+nb7kqTqc1KZ/yiHzet9o6XWLgV1POsbaTUUE+x1Hzcqsv0q EwU8Ja3Uta5ueLP7eehbyFoadFBiH/nqLtHU2OWkyqn3ImNrGHx7fLYKw8giufhC o4Xw4PktB+c= =Bu0v -----END PGP SIGNATURE-----

Comments? Click here http://www.auscert.org.au/render.html?cid=43&it=5313