-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

===========================================================================
A  U  S  C  E  R  T                                           A  L  E  R  T

                        AL-2004.12 -- AusCERT ALERT
                        Vulnerability Issues in TCP
                    NISCC Vulnerability Advisory 236929
                               21 April 2004

===========================================================================

        AusCERT Alert Summary
        ---------------------

Product:                Transmission Control Protocol (TCP)
Publisher:              NISCC
Impact:                 Denial of Service
                        Reduced Security
Access Required:        Remote
CVE Names:              CAN-2004-0230

Ref:                    ESB-2001.179

Due to the severity of this vulnerability AusCERT is releasing this
information as an AusCERT Alert. AusCERT recommends that sites which use
a vulnerable implementation (for details, see the "Vendor Information"
section) should either upgrade or apply the patch as described at:

 http://www.uniras.gov.uk/vuls/2004/236929/index.htm

Alternatively, site should consider implementing the workaround steps in
the "Mitigation" section.

A publically available exploit tool exists for this vulnerability.

- --------------------------BEGIN INCLUDED TEXT--------------------

Title
=====

NISCC Vulnerability Advisory 236929 - Vulnerability Issues in TCP


Detail
====== 



Version Information 
- -------------------
Advisory Reference  236929 
Release Date        20 April 2004 
Last Revision       20 April 2004 
Version Number      1.0 
 

What is Affected?
- -----------------
The vulnerability described in this advisory affects implementations of the
Transmission Control Protocol (TCP) that comply with the Internet
Engineering Task Force’s (IETF’s) Requests For Comments (RFCs) for TCP,
including RFC 793, the original specification, and RFC 1323, TCP Extensions
for High Performance.

TCP is a core network protocol used in the majority of networked computer
systems today. Many 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 TCP connection will also be
impacted, the severity depending primarily on the duration of the TCP
session. 


Severity
- --------
The impact of this vulnerability varies by vendor and application, but in
some deployment scenarios it is rated critical. Please see the vendor
section below for further information. Alternatively contact your vendor
for product specific information.

If exploited, the 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 duration of the TCP connection, with a further dependency on knowledge
of the network (IP) addresses of the end points of the TCP connection.

The Border Gateway Protocol (BGP) is judged to be potentially most affected
by this vulnerability.

BGP relies on a persistent TCP session 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 moderate
based on the likelihood of successful attack. If the TCP MD5 Signature
Option and anti-spoofing measures are used then the impact will be low as
these measures will successfully mitigate the vulnerability.

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 duration of the
sessions is relatively short and the sessions can be restarted without
medium term unavailability problems. In the case of SSL it may be difficult
to guess the source IP address.

Data injection may be possible. However, this has not been demonstrated and
appears to be problematic. 


Summary
- -------
The issue described in this advisory is the practicability of resetting an
established TCP connection by sending suitable TCP packets with the RST
(Reset) or SYN (Synchronise) flags set.

The packets need to have source and destination IP addresses that match the
established connection as well as the same source and destination TCP
ports.

The fact that TCP sessions can be reset by sending suitable RST and SYN
packets is a design feature of TCP according to RFC 793, but a reset attack
is only possible at all because the source IP address and TCP port can be
forged or “spoofed”.

Although denial of service using crafted TCP packets is a well known
weakness of TCP, until recently it was believed that a successful denial of
service attack was not achievable in practice. The reason for this is that
the receiving TCP implementation checks the sequence number of the RST or
SYN packet, which is a 32 bit number, giving a probability of 1/2^32 of
guessing the sequence number correctly (assuming a random distribution).

The discoverer of the practicability of the RST attack was Paul A. Watson,
who describes his research in his paper “Slipping In The Window: TCP Reset
Attacks”, presented at the CanSecWest 2004 conference. He noticed that the
probability of guessing an acceptable sequence number is much higher than
1/2^32 because the receiving TCP implementation will accept any sequence
number in a certain range (or “window”) of the expected sequence number.
The window makes TCP reset attacks practicable.

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 at least denial of service
attacks. 


Details
- -------
TCP is the transport layer protocol designed to provide connection-oriented
reliable delivery of IP packets. To do 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 acknowledgement number, that is used
to indicate the sequence number of the next packet expected. The packets
are reassembled by the receiving TCP implementation only if their sequence
numbers fall within a range of the acknowledgement number (called a
"window"). The acknowledgement number is not used in a RST packet because a
reset does not expect a packet in return. (To be completely accurate,
although the last statement is true for a RST packet without the ACK flag
set, used to indicate that a TCP port is closed, a RST/ACK is used to
terminate an active connection in the event of error. In a RST/ACK packet
an acknowledgement number is included in the packet, although it is not
checked by the receiving TCP implementation.)

RFC 793, p36, states the following:

"In all states except SYN-SENT, all reset (RST) segments are validated by
checking their SEQ-fields [sequence numbers]. A reset is valid if its
sequence number is in the window. In the SYN-SENT state (a RST received in
response to an initial SYN), the RST is acceptable if the ACK field
acknowledges the SYN."

Resets must be processed immediately. RFC 793, p25, says "[…] [E]ven when
the receive window is zero, a TCP must process the RST and URG fields of
all incoming segments."

It is also possible to perform the same attack with SYN (synchronise)
packets. An established connection will abort by sending a RST if it
receives a duplicate SYN packet with initial sequence number within the TCP
window. RFC 793, p31 states:

“The principle reason for the three-way handshake is to prevent old
duplicate connection initiations from causing confusion. To deal with this,
a special control message, reset, has been devised. […] If the TCP is in
one of the synchronized states (ESTABLISHED, FIN-WAIT-1, FIN-WAIT-2,
CLOSE-WAIT, CLOSING, LAST-ACK, TIME-WAIT), it aborts the connection and
informs its user.”

TCP window sizes are negotiated in the initial 3-way handshake used to set
up a TCP connection, with higher values serving to improve throughput in
some circumstances. Vendor-chosen defaults also influence the selection. In
any case, the larger the window size, the greater is the probability that a
randomly chosen TCP sequence number will lie within the window range. This
is the basis for the attack.

A TCP connection is defined by a 4-tuple comprising source and destination
IP addresses, and source and destination ports. An attacker seeking to
disrupt an existing TCP connection must supply the 4-tuple correctly. As
the source port varies, additional work is generally called for on the part
of the attacker. However, research (referenced below) has shown that the
process of source port selection on many platforms includes predictable
elements, so that the attack remains practicable. By weighting 'likely'
source port values carefully, an attacker can disrupt TCP implementations
that employ a range of window sizes.

Application layer protocols that are critically affected are those that:

  •  Depend on long lived TCP connections
 
  •  Have known or easy-to-guess IP address end points 

  •  Have easy to an easy-to-guess source TCP port 

As noted above BGP does use long lived TCP connections, and the IP
addresses and source port (and destination port) are sometimes available
through the use of BGP looking glasses (multi-source, multi-destination
trace route tools) or DNS resource records. Using “trace route” commands
can provide information on peering point IP addresses. Thus BGP is likely
to be critically affected by the TCP vulnerability.

These denial of service attacks can be carried out by single machine, or by
multiple co-operating systems (to form a distributed denial of service
attack).

It is also possible to inject packets, which will be processed if they are
in the window. The difficulty with data injection attacks is that the
receiving TCP implementation will reassemble the packets received according
to sequence number, dropping any duplicate packets.


Vendor specific information will be released as it becomes available and if
vendor permission has been received. Subscribers are advised to check the
following URL regularly for updates:

http://www.uniras.gov.uk/vuls/2004/236929/index.htm

[Please note that updates to this advisory will not be notified by email.]

This vulnerability has been assigned the CVE name CAN-2004-0230.
[http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230]

The Open Source Vulnerability Database ID number for this vulnerability is 4030.
[http://www.osvdb.org/displayvuln.php?osvdb_id=4030]


Mitigation
- ----------
The following mitigation steps are still being evaluated and may be
incomplete. Customers should work with vendors for the workaround most
appropriate for the product in question.

In the absence of vendor patching of the TCP implementation, the following
are general mitigating steps:

  •  Implement IP Security (IPSEC) which will encrypt traffic at the
     network layer, so TCP information will not be visible

  •  Reduce the TCP window size (although this could increase traffic loss
     and subsequent retransmission)

  •  Do not publish TCP source port information 

It should be noted that IPSEC provides confidentiality and authentication
services at the network layer, and can provide a measure of trust in the
authenticity of the end points as well as encryption of traffic between the
end points.  However, in the context of the current attack IPSEC will
reject RST and SYN packets that are not part of a secure IP packet stream.

To change the TCP window size, in some Unix variants you can set a value of
the default TCP windows size by using the “sysctl” program (“ndd -set” in
the case of Sun Solaris). In the case of Microsoft Windows NT/2000/XP/2003,
the default window size can be changed by modifying the value of the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters key.
As noted above, great care should be exercised when altering the default
TCP window size as network performance could be adversely affected.

In the case of BGP, the following may counter the problem:

  •  Implement ingress and egress filtering to check that the traffic
     entering or leaving the network has a source IP address that is
     expected on the router/firewall interface that receives the traffic

  •  Implement the TCP MD5 Signature Option to checksum the TCP packet
     carrying the BGP application data (see RFC 2385), being careful to set
     and maintain strong (i.e. difficult to guess) passwords to which the
     MD5 checksum is applied.  Also see RFC 3562 which discusses the
     security requirements of this keying material.

  •  Limit the amount of information available through looking glasses and
     DNS resource records, being careful not to expose TCP port information
     unnecessarily 

The IETF ingress filtering standard is defined in RFC 2827. A discussion of
egress filtering can be found at http://www.sans.org/y2k/egress.htm.

The use of the TCP MD5 Signature Option will prevent the exploitation of
this vulnerability. Router customers should implement this on all BGP
peering points if it is supported by the router, upgrading the router
firmware if necessary.


Solution
- --------
Please refer to the Vendor Information section of this advisory for
implementation specific remediation.

Some vendors will have reduced the likelihood of successful denial of
service by amending the TCP implementation to issue a further
acknowledgment packet challenge for RST and SYN packets that do not have
exactly the expected sequence number.

The Internet Engineering Task Force (IETF) has published an Internet Draft
to co-incide with the release of this advisory.  The text of this draft is
available from the IETF web site:
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt

NISCC has produced best practice guidelines for BGP available at
http://www.niscc.gov.uk/BGP Filtering Guide.pdf

Secure configuration templates for BGP implementations on Cisco IOS and
Juniper JunOS can be found at:

  •  Cisco    http://www.cymru.com/Documents/secure-bgp-template.html  

  •  Juniper  http://www.qorbit.net/documents/junos-bgp-template.pdf  

Guidance on tuning of the IP stack for a number of different UNIX operating
systems is available at http://www.cymru.com/Documents/ip-stack-tuning.html 


Vendor Information 
- ------------------
A list of vendors affected by this vulnerability is available from the web
site at http://www.uniras.gov.uk/vuls/2004/236929/index.htm


Acknowledgements
- ----------------
NISCC wishes to thank the following:

  •  Steve Bellovin, Rob Thomas and Paul Watson for their contributions to
     this advisory.

  •  Cisco Systems Inc. and Juniper Networks Inc. for their help with the
     content of this advisory and for their support during the disclosure
     process.

  •  JPCERT/CC for their assistance in co-ordinating this disclosure in
     Japan. 


References
- ----------

  Internet Engineering Task Force

   - RFC 793  Transmission Control Protocol
      http://www.ietf.org/rfc/rfc793.txt

   - RFC 1323 TCP Extensions for High Performance
      http://www.ietf.org/rfc/rfc1323.txt

   - RFC 1771 A Border Gateway Protocol 4 (BGP-4)
      http://www.ietf.org/rfc/rfc1771.txt

   - RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option
      http://www.ietf.org/rfc/rfc2385.txt

   - RFC 2827 Network Ingress Filtering
      http://www.ietf.org/rfc/rfc2827.txt

   - RFC 3562 Considerations for the TCP MD5 Signature Option
      http://www.ietf.org/rfc/rfc3562.txt

   - Internet Draft - Secure TCP
      http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt


  NISCC

   - Web site version of this advisory including vendor impact statements
      http://www.uniras.gov.uk/vuls/2004/236929/index.htm

   - Best Practice Guidelines - Border Gateway Protocol
      http://www.niscc.gov.uk/BGP Filtering Guide.pdf 


  Configuration and Tuning Guides

   - Secure BGP Template for Cisco IOS
      http://www.cymru.com/Documents/secure-bgp-template.html

   - JUNOS Secure BGP Template
      http://www.qorbit.net/documents/junos-bgp-template.pdf

   - UNIX IP Stack Tuning Guide
      http://www.cymru.com/Documents/ip-stack-tuning.html


  Other Documents

   - SANS discussion on egress filtering
      http://www.sans.org/y2k/egress.htm


  Vulnerability Databases
  
   - Common Vulnerabilities and Exposures (CVE)
      http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230

   - Open Source Vulnerability Database (OSVDB)
      http://www.osvdb.org/displayvuln.php?osvdb_id=4030

What is NISCC?
- --------------
For further information regarding the UK National Infrastructure Security
Co-ordination Centre, please visit
http://www.niscc.gov.uk/aboutniscc/index.htm.
 
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.

© 2004 Crown Copyright

<End of NISCC Vulnerability Advisory>

- ----------------------------------------------------------------------------------
UNIRAS wishes to acknowledge the contributions of NISCC for the information 
contained in this Briefing. 
- ----------------------------------------------------------------------------------
This Briefing contains the information released by the original author. Some 
of the information may have changed since it was released. If the vulnerability 
affects you, it may be prudent to retrieve the advisory from the canonical site 
to ensure that you receive the most current information concerning that problem.

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 UNIRAS or NISCC.  The views 
and opinions of authors expressed within this notice shall not be used for 
advertising or product endorsement purposes.

Neither UNIRAS or NISCC shall also accept responsibility for any errors 
or omissions contained within this briefing notice. 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.

UNIRAS is a member of the Forum of Incident Response and Security Teams (FIRST) 
and has contacts with other international Incident Response Teams (IRTs) in 
order to foster cooperation and coordination in incident prevention, to prompt 
rapid reaction to incidents, and to promote information sharing amongst its 
members and the community at large. 
- ----------------------------------------------------------------------------------
<End of UNIRAS Briefing>

- --------------------------END INCLUDED TEXT--------------------

This alert 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 alert.  It may not be
updated when updates to the original are made.  If downloading at a later
date, it is recommended that the alert 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 alert above.  If you have any questions or need further information,
please contact them directly.

Previous advisories, alerts and external security bulletins can be 
retrieved from:

        http://www.auscert.org.au/render.html?cid=1977

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

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

iQCVAwUBQIWnuCh9+71yA2DNAQIg1QP/Z/cUhpFisDrqnHqxfDit0xRE53YFaUE7
L4G6uoK8mdsUOv/w9/bHIhZaiDmkOPE3FT0hbXPBDMk9uEldZeTfH1FxkS/hvV/M
Xs5YptzMhXMd3a79Sp20VEowpE2Sn59g/NEgqDYTj9GrdRPUS1tjxcSUT8H4wVmy
rx3f4sBlJsc=
=fkXm
-----END PGP SIGNATURE-----