FTPEXT Working Group G. Lundberg Internet-Draft WU-FTPD Development Group Expiration Date: November 28, 2002 May 2002 FTP Data Connection Assurance draft-ietf-ftpext-data-connection-assurance-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. To view the list of IETF Internet-Draft Mirror Sites, see http://www.ietf.org/shadow.html. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies an extension to the File Transfer Protocol (FTP) by which a user and server can exchange data port connection information which may then be used to provide connection assurance. Two new commands are introduced. Through use of these commands and their replies, the user and server exchange information allowing verification of the socket addresses for a data connection prior to actual data transmission over the connection. Implementation of this extension is RECOMMENDED. Lundberg Expires November 28, 2002 [Page 1] Internet-Draft FTP Data Connection Assurance May 2002 Table of Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. ACTIVE ESTABLISH (ESTA) . . . . . . . . . . . . . . . . . . . 5 3. PASSIVE ESTABLISH (ESTP) . . . . . . . . . . . . . . . . . . . 8 4. Connection Management . . . . . . . . . . . . . . . . . . . . 11 5. FEAT Response . . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 Normative References . . . . . . . . . . . . . . . . . . . . . 14 Informative References . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 Annex A - Address Family Numbers . . . . . . . . . . . . . . . 16 Annex B - Network Address Formats . . . . . . . . . . . . . . 16 Annex C - Examples of Use . . . . . . . . . . . . . . . . . . 16 C.1 PORT Mode . . . . . . . . . . . . . . . . . . . . . . . 17 C.2 PASV Mode . . . . . . . . . . . . . . . . . . . . . . . 18 C.3 Server-to-Server Mode . . . . . . . . . . . . . . . . . 19 Annex D - Implementation Considerations . . . . . . . . . . . 21 D.1 Interactively Finding the Specified Connection . . . . 21 D.2 Automatically Finding the Specified Connection . . . . 22 D.3 Using a Common Passive Socket . . . . . . . . . . . . . 22 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 24 Lundberg Expires November 28, 2002 [Page 2] Internet-Draft FTP Data Connection Assurance May 2002 1. Introduction The intention of this protocol extension is to address the security issue involved with the problem of a race condition in the existing File Transfer Protocol [DS, CERT2]. This condition allows an attacker the ability to receive unauthorized transmissions from, or transmit unauthorized information to, the passive party of a file transfer. The attack makes use of the timing window between when the passive socket is prepared and when an active connection to that passive socket actually occurs. The security industry identifier for this issue is CVE-1999-0351 [CVE]. The problem is fairly well known within the FTP community and has been discussed for some time [DS]. Since it does not pose a direct threat to the security of hosts on the Internet, and generally presents only limited inconvenience to users, little attention has been paid to the issue. It is, however, a growing concern to a number of private, corporate and governmental users who desire assurance that their information is delivered only to the intended recipients yet who are unwilling to sacrifice availability or inter- operability by use of cryptographic methods [RFC2228, MURRAY]. The fact that the FTP makes no attempt to prevent, or even provide a means to detect, these events is unacceptable. Several independent implementations of attacks making use of this window are known to exist [KS, JG], and at least one event has been claimed to have occurred against a vendor site to obtain unauthorized copies of potentially proprietary information. To date, all known attacks depend upon weaknesses in TCP implementations, but with the relatively small number of TCP ports and advances in distributed attack methods this condition cannot be expected to continue. To fully understand the problem, and the solution presented, a basic understanding of some features of the FTP is required. The FTP model [RFC959] uses two communication channels: the data connection is responsible for exchanging files and other data; the control connection provides control and synchronization of the data connection and transmissions over it. While the control connection exists throughout the lifetime of an FTP session, data connections are often transitory, existing only for the duration of a single file transfer. The FTP model is usually presented as two processes: the User-FTP implementation and the Server-FTP implementation. Each of these processes are further separated into the protocol interpreter (PI) Lundberg Expires November 28, 2002 [Page 3] Internet-Draft FTP Data Connection Assurance May 2002 and the data transfer process (DTP). A Server-FTP always implements both a PI and a DTP. The User-FTP, however, may implement only a PI; using an external process as its DTP (as is the case, for example, in a server-to-server transfer). Existing FTP commands [RFC959, RFC1639, RFC2428] allow the user to determine which end-point has responsibility for actively initiating the data connection. The other end-point passively awaits this connection. To cause the Server-DTP to operate in passive mode, the user sends a PASV, LPSV or EPSV command, requesting the Server-DTP create a passive socket and report the address assigned. To cause the Server-DTP to operate in active mode, the user creates (or obtains through other means) a passive socket and communicates its address to the Server-FTP process through the PORT, LPRT or EPRT commands. The user actively initiates the data connection immediately prior to issuing the data transfer command. (It may do so any time after receipt of the reply to the PASV, LPSV or EPSV command, and must do so prior to issuing the data transfer command.) The Server-FTP process must initiate the data connection upon receipt of the data transfer command and prior to issuing a reply to that command. The delay involved, between the creation of the passive socket and establishment of the data connection using it, presents a window during which an attacker can actively establish a connection to the passive socket. Unfortunately, the FTP provides no means to assure that the active socket is the one intended; the passive participant simply accepts the first connection presented. While all parties have knowledge of the address assigned to the passive socket, only the process actively initiating the connection knows the address of the active socket. Without some means of communicating this information to all parties, there is insufficient information to judge whether the connection originated from the intended participant. The protocol presented is intended to provide just that: a means to exchange active socket address information. In the development of the protocol specified in this document, several alternatives were considered. The STAT command [RFC959] could be issued by the user to discover the address of the active socket. The format of the reply to the STAT command, however, is not well defined; to be usable, a consistent, machine readable response is needed. Requiring the reply to the STAT command to provide the necessary information in a usable fashion Lundberg Expires November 28, 2002 [Page 4] Internet-Draft FTP Data Connection Assurance May 2002 would cause inter-operation problems with existing implementations, and is only a partial solution since it does not address the needs of the Server-FTP process when operating in passive mode. Some existing Server-FTP implementations attempt to reduce the impact of the problem by placing requirements upon which remote socket addresses they will accept [GL]. These requirements violate the spirit, if not the letter, of the FTP specifications, negatively impacting its usability, and can raise complex configuration issues for server administrators. In addition, these methods are only a partial solution since they do not address the needs of the user. [DS] suggests exchanging verification information over the control and data connections, however doing so would prevent inter- operability with existing implementations. Existing specifications [RFC2228, MURRAY] can provide just such a solution but are not widely deployed and, to assure connection integrity, do not inter-operate with existing (non-cryptographic) implementations. What is required is a solution which addresses the problem for all parties, operates with little added overhead and minimal (optimally, no) configuration requirements, does not break inter-operability with existing implementations, and which is straightforward to deploy, without the processing overhead and potential legal issues involved with cryptographic methods. The new commands presented here provide for the exchange the active socket address between the user and the Server-FTP process. This presents both parties (or, in the case of server-to-server transfers, all three parties) with the information necessary to evaluate the connection end-points prior to commencing transmission. When reading the following specifications, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119]. 2. ACTIVE ESTABLISH (ESTA) The user should issue the ESTA command before issuing any other data transfer command when the Server-DTP is in active mode and a usable data connection is not already present. This command instructs the Server-DTP to immediately establish a connection from its data port to the currently selected passive address, and to report back to the user the address information for the active socket actually used on the new connection. Lundberg Expires November 28, 2002 [Page 5] Internet-Draft FTP Data Connection Assurance May 2002 The active socket on the connection is the local address. In [POSIX], for example, this is the value returned via the getsockname function; which may differ from the address requested by the bind function. The user must have already prepared a passive socket to accept the connection, and communicated the address information for that socket to the Server-FTP process using the PORT, LPRT or EPRT command. For a server-to-server transfer, this means the user must have already successfully instructed the other, passive Server-DTP to prepare the passive socket. If the Server-DTP has already accepted an established data connection to the passive socket, it should report the local address for that connection. Thus, the ESTA command is repeatable, and may be issued to either server in a server-to-server transfer at any time that the user wishes the server to report the local address it observes on the fully established data connection. The establishment of the connection may take some time, and the Server-DTP may make several attempts before reporting a failure. The implementation should include a time out limiting the duration of the connection attempts. The Server-FTP process should be capable of accepting the ABOR command during this period, and should interpret the ABOR command as a request to cease the connection attempt or close the connection if the attempt has already succeeded. The ESTA command is analogous to the PASV, LPSV and EPSV commands, and returns a result formatted the same as that which would be produced by the EPSV command [RFC2428] (even if the EPSV command is not implemented). The format of the ESTA command is: ESTA The ESTA command takes no arguments. Possible replies to the ESTA command, and their meanings, include: 225 Data connection open; no transfer in progress. 421 Service not available, closing control connection. 425 Can't open data connection. 500 Syntax error, command unrecognized. 501 Syntax error in parameters or arguments. 502 Command not implemented. 520 Requested action not taken; DTP is in passive mode. Lundberg Expires November 28, 2002 [Page 6] Internet-Draft FTP Data Connection Assurance May 2002 With the exception of response code 225, the User-FTP process must not depend upon the actual text (if any) included with the reply. A Server-FTP process which does not implement the ESTA command will reply with either response code 500 or 502. For compatibility with existing implementations, the User-FTP process must be prepared for this reply. It should be possible to proceed with the data transfer. Local site policy, however, may dictate refusal to continue communication with implementations which do not support ESTA. The response code 520 indicates that the Server-DTP was unable to accept a connection from the passive socket because it is operating in passive mode and does not have the address of a remote passive socket to connect to. This should not occur if there is already a fully established data connection. The response code 425 indicates that the Server-DTP was unable to establish a connection to the passive socket. This should not occur if there is already a fully established data connection. In [POSIX], for example, this would occur when the connect function returns an error indication; possible causes might include a refused connection, an unreachable passive socket address, time-out, resource depletion, or internal implementation errors. Response code 225 indicates that the Server-DTP has established a connection to the passive socket, or already had a fully established data connection. The Server-FTP process must format the text of reply for response code 225 in a manner similar to a positive completion reply to the EPSV command (even if the EPSV command is not actually implemented). Unlike the EPSV reply, the Server-FTP process must include the full protocol address information actually observed on the data connection for the local socket in the ESTA report. Upon receipt of reply 225, the user's DTP should accept the connection from the passive socket and then the User-FTP process should compare the information provided with the reply against that obtained locally from the established connection. If the two do not exactly match, the user should terminate the data connection by issuing the ABOR command, and should not proceed to issue a data transfer command. For a server-to-server transfer, the information provided in the response to ESTA should be compared with the information provided in the response to the ESTP command. For the User-FTP process, the information provided in the response to ESTA should be compared Lundberg Expires November 28, 2002 [Page 7] Internet-Draft FTP Data Connection Assurance May 2002 against the remote address observed on the fully established data connection. In [POSIX], for example, this is the value returned via the address argument to the accept function. The format of the response code 225 reply is: 225 () The unformatted text portion of the reply () may be any message, and may be omitted. If present, it must be separated from the formatted portion of the reply by at least one space character. The formatted portion of the reply must be enclosed in parentheses, formatted exactly as the arguments to the ESTP command (below), and has the same meaning. Following the separating space and parenthesis, a delimiter character () must be specified. The delimiter character must be one octet in range 33 to 126, inclusive. The character "|" (ASCII 124) is recommended; unless it coincides with a character needed to encode the arguments. Note that the discussion which follows presumes the use of TCP over an Internet Protocol but should not be taken as a requirement that only those protocols may be used: from the point of view of the ESTA command, any protocol is acceptable. The number and meaning of any arguments which follow is protocol-specific; this memo specifies the arguments for TCP over the Internet Protocols in use at the time of its writing. The protocol argument () must be an address family number assigned by the IANA. This number indicates the protocol to be used (and, implicitly, the number, meaning, and maximum lengths, of the remaining arguments). The network address argument () is a protocol-specific string representation of the network address for the active socket observed on the connection. Refer to Annex B for the formats required for the Internet Protocols. The port number argument () must be the string representation of the number of the TCP port used by the active socket observed on the connection. 3. PASSIVE ESTABLISH (ESTP) The user should issue the ESTP command before issuing any other data transfer command when the Server-DTP has been placed in passive mode Lundberg Expires November 28, 2002 [Page 8] Internet-Draft FTP Data Connection Assurance May 2002 and a usable data connection is not already present. This command instructs the Server-DTP to accept a connection from the passive socket listening on its data port, and to report back to the user the address information for the active socket observed on the new connection. The active socket observed on the connection is the remote address. In [POSIX], for example, this is the value returned via the address argument to the accept function. The user must have already established an active connection to the Server-DTP using the address and port information previously obtained from the PASV, LPSV or EPSV command. For a server-to-server transfer, this means the user must have already successfully instructed the other, active Server-DTP to establish the connection. If the Server-DTP has already accepted an established data connection from the passive socket, it should report the remote address for that connection. Thus, the ESTP command is repeatable, and may be issued to either server in a server-to-server transfer at any time that the user wishes the server to report the remote address it observes on the fully established data connection. The Server-DTP must not await new connections on the passive socket. The ESTP command indicates the user believes an established connection already exists. If this is not the case, the Server-DTP must immediately report this fact. The ESTP command is analogous to the PORT, LPRT and EPRT commands, and requires a parameter formatted the same as that which would be provided with the EPRT command [RFC2428] (even if the EPRT command is not implemented). The protocol, network address and port information provided with the command must be that of the active socket. In a server-to-server transfer, the address of the active socket is returned in the response to the ESTA command. For the User-FTP process, this address is the local information observed on the established active connection. In [POSIX], for example, this is the value returned via the getsockname function; which may differ from the address requested by the bind function. The format of the ESTP command is: ESTP The ESTP command keyword must be followed by a single space character (ASCII 32). Following the space, a delimiter character () must be Lundberg Expires November 28, 2002 [Page 9] Internet-Draft FTP Data Connection Assurance May 2002 specified. The delimiter character must be one octet in range 33 to 126, inclusive. The character "|" (ASCII 124) is recommended; unless it coincides with a character needed to encode the arguments. Note that the command format shown, and the discussion which follows, presume the use of TCP over an Internet Protocol but should not be taken as a requirement that only those protocols may be used: from the point of view of the ESTP command, any protocol is acceptable. The number and meaning of any arguments which follow is protocol-specific; this memo specifies the arguments for TCP over the Internet Protocols in use at the time of its writing. The protocol argument () must be an address family number assigned by the IANA. This number indicates the protocol to be used (and, implicitly, the number, meaning, and maximum lengths, of the remaining arguments). The network address argument () is a protocol-specific string representation of the network address for the active socket observed on the connection. Refer to Annex B for the formats required for the Internet Protocols. The port number argument () must be the string representation of the number of the TCP port used by the active socket observed on the connection. Possible replies to the ESTP command, and their meanings, include: 225 Data connection open; no transfer in progress. 421 Service not available, closing control connection. 425 Can't open data connection. 500 Syntax error, command unrecognized. 501 Syntax error in parameters or arguments. 502 Command not implemented. 520 Requested action not taken; DTP is in active mode. With the exception of response code 225, the User-FTP process must not depend upon the actual text (if any) included with the reply. A Server-FTP process which does not implement the ESTP command will reply with either response code 500 or 502. For compatibility with existing implementations, the User-FTP process must be prepared for this reply. It should be possible to proceed with the data transfer. Local site policy, however, may dictate refusal to continue communication with implementations which do not support ESTP. The response code 520 indicates that the Server-DTP was unable to accept a connection from the passive socket because it is operating Lundberg Expires November 28, 2002 [Page 10] Internet-Draft FTP Data Connection Assurance May 2002 in active mode and there is no passive socket. This should not occur if there is already a fully established data connection. The response code 425 indicates that the Server-DTP was unable to accept a connection from the passive socket. This should not occur if there is already a fully established data connection. In [POSIX], for example, this would occur when the accept function returns an error indication; possible causes might include an aborted connection, resource depletion, or internal implementation errors. Response code 225 indicates that the Server-DTP has accepted a passive data connection, or already had a fully established data connection. The Server-FTP process must format the text of reply for response code 225 in a manner similar to a positive completion reply to the EPSV command (even if the EPSV command is not actually implemented). Unlike the EPSV reply, the Server-FTP process must include the full protocol address information actually observed on the data connection for the remote socket in the ESTP report. Upon receipt of reply 225, the User-FTP process should compare the information provided with the reply against that obtained locally from the established connection. If the two do not exactly match, the user should terminate the data connection by issuing the ABOR command, and should not proceed to issue a data transfer command. The format of the response code 225 reply is: 225 () The unformatted text portion of the reply () may be any message, and may be omitted. If present, it must be separated from the formatted portion of the reply by at least one space character. The formatted portion of the reply must be enclosed in parentheses, formatted exactly as the arguments to the ESTP command, and has the same meaning. 4. Connection Management Implementations should, for the purposes of connection management, treat the ESTA and ESTP commands as data transfer commands. As data transfer commands, the addition of the ESTA and ESTP commands does not significantly change connection management requirements. Lundberg Expires November 28, 2002 [Page 11] Internet-Draft FTP Data Connection Assurance May 2002 Since these commands leave the connection established, but unused, a subsequent data transfer command should not cause establishment of a new data connection; the implementation should see that it has an established connection suitable for use with the desired data transfer and proceed to use that connection. 5. FEAT Response The specifications for the ESTA and ESTP commands provide the means to reliably determine the Server-FTP process's support for the commands. The user may issue a FEAT command [RFC2389] prior to use of the ESTA or ESTP command. This may allow the user to determine if the Server- FTP process supports these commands. However, since deployment of Server-FTP implementations which support the FEAT command is not yet wide-spread, the user should not rely upon implementation of the FEAT command to indicate implementation of the ESTA and ESTP commands. A Server-FTP which implements the ESTA and ESTP commands may (from the point of view of this specification) implement the FEAT command. If so, it must include, in the response to the FEAT command, a feature line indicating support for the ESTA and ESTP commands. The feature line must be formatted as: ESTA As specified in [RFC2389], the feature-name text, "ESTA," is not case sensitive, but should be transmitted in upper-case, and the feature line must begin with a single space character and end with a normal Telnet end-of-line sequence. At this time, options are not envisioned for either command. To allow separate options for ESTA and ESTP, the user should also accept the text "ESTP" as indicating support for both commands. The user, however, should accept options on the FEAT response and discard any it does not recognize. When options appear, they must be separated from the feature-name text by exactly one space character. 6. IANA Considerations The specifications in this memo make reference to assignment lists currently maintained by the Internet Assigned Numbers Authority (IANA); no new assignments are specified, and no new assignment lists are required. The list of valid feature names sent in response to the FTP FEAT Lundberg Expires November 28, 2002 [Page 12] Internet-Draft FTP Data Connection Assurance May 2002 command is believed to be first-come first-served, and managed outside the control of the IANA. Specific examples taken from IANA-maintained lists at the time of this writing are for illustrative and informative purposes only. 7. Security Issues The ESTP command, and the replies to both ESTA and ESTP, contain network addressing information which could be used to gather information about internal network architectures. However, since similar information is already transmitted on the FTP control connection, it presents no risk not already present in the FTP. The intention of this protocol extension is to address the security issue involved with the problem of a race condition in the existing File Transfer Protocol [DS, CERT2]. This condition allows an attacker the ability to receive unauthorized transmissions from, or transmit unauthorized information to, the passive party of a file transfer. The attack makes use of the timing window between when the passive socket is prepared and when an active connection to that passive socket actually occurs. The security industry identifier for this issue is CVE-1999-0351 [CVE]. Denial of Service attacks can make use of this issue. The described protocol is equally susceptible to Denial of Service attacks. It can, however, make their effect much more apparent since data transfers will fail where they may have incorrectly appeared to have succeeded without these protocol extensions. The described protocol does not address the issue of "FTP Bounce" (CVE-1999-0017); where an attacker, via the control connection, instructs the Server-DTP to actively establish a data connection to a third party [CERT1]. The protocol presented also makes no attempt to secure the actual data transmission; it only provides a means to determine the proper data connection has been established prior to initiating data transfer over that channel. Alternatives, such as provided by the FTP Security Extensions [RFC2228, MURRAY], should be considered when data security is an issue. Unfortunately, these methods are not, as yet, widely deployed. ([MURRAY] is a work in process. Wide spread deployment, if it occurs at all, will be some time in the future.) The extensions provided by this protocol provide added measures which can compliment those alternatives, but cannot replace them. Lundberg Expires November 28, 2002 [Page 13] Internet-Draft FTP Data Connection Assurance May 2002 The use of any Network Address Translation scheme, or certain proxy implementations, may render this protocol unusable. The protocol involves the transmission of network address information over the FTP control connection. Address translators, including proxy implementations which do not implement this protocol, can cause a mismatch between the information transmitted and the address actually observed at the communication channel end-point. Acknowledgments The following people provided significant assistance with the analysis of the problem, the proposed solution, and the preparation of this document: The members of vulnerability handling team at the CERT Coordination Center. Paul Ford-Hutchinson of IBM UK Ltd. Ian Willis of Sun Microsystems. Normative References [RFC959] J. Postel and J. Reynolds, "FILE TRANSFER PROTOCOL (FTP)", STD 9, RFC 959, October 1985. [RFC1123] IETF, "Requirements for Internet Hosts -- Application and Support", STD 3, RFC 1123, October 1989. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirements Levels", RFC 2119, BCP 14, March 1997. [RFC2389] P. Hethmon and R. Elz, "Feature negotiation mechanism for the File Transfer Protocol", RFC 2389, August 1998. [RFC2428] M. Allman, S. Ostermann and C. Metz, "FTP Extensions for IPv6 and NATs", RFC 2428, September 1998. Informative References [RFC1639] D. Piscitello, "FTP Operation Over Big Address Records (FOOBAR)", RFC 1639, June 1994. [RFC2228] M. Horowitz and S. Lunt, "FTP Security Extensions", RFC 2228, October 1997. [MURRAY] P. Ford-Hutchinson, et al, "Securing FTP with TLS", IETF Internet-Draft, Work in process. Lundberg Expires November 28, 2002 [Page 14] Internet-Draft FTP Data Connection Assurance May 2002 [POSIX] IEEE and The Open Group, "Base Specifications, Issue 6", IEEE Std 1003.1-2001, January 2001. The following references are only available electronically. The URL given for each is believed to be the "original source." At least one is known to be no longer available from that source. All documents cited, however, are widely mirrored and known to be readily located using search engines. [DS] D. Sacerdote, "Some problems with the File Transfer Protocol, a failure of common implementations, and suggestions for repair.", http://www.secnet.com/papers/ftp-paper.html, April 1996. [CERT1] CERT Coordination Center, "Problems with the FTP PORT Command or Why You Don't Want Just Any PORT in a Storm", http://www.cert.org/tech_tips/ftp_port_attacks.html, April 1998. [JG] J. Gerber, "FTP PASV "Pizza Thief" Exploit", http://www.infowar.com/iwftp/iw_sec/iw_sec_01.txt, February 1999. [GL] G. Lundberg, "Security update for wu-ftpd 2.4.2 (beta 18) VR13", ftp://ftp.wu-ftpd.org/pub/wu-ftpd- attic/ANNOUNCE-2.4.2-beta-18-vr14, February 1999. [CVE] Mitre Corp., "Common Vulnerabilities and Exposures", http://cve.mitre.org/, September 1999. [KS] K. Seifried, "Problems with the FTP protocol", http://seifried.org/security/network/20010926-ftp- protocol.html, September 2001. [CERT2] J. Lanza and J. Pickel, "File Transfer Protocol allows data connection hijacking via PASV mode race condition", http://www.kb.cert.org/vuls/id/2558, April 2002. Author's Address Gregory A. Lundberg WU-FTPD Development Group 1441 Elmdale Drive Dayton, OH 45409-1615 US Phone: +1 937 299 7653 Email: lundberg@vr.net Lundberg Expires November 28, 2002 [Page 15] Internet-Draft FTP Data Connection Assurance May 2002 Annex A - Address Family Numbers The ESTP command, and the responses to both ESTA and ESTP, make use of the address family number. For informational purposes, the following table shows the assignments for the Internet Protocols as of the writing of this document. Refer to the IANA for a current list of all address family numbers. AF Number Protocol --------- -------- 1 Internet Protocol, Version 4 (STD 5, RFC 791) 2 Internet Protocol, Version 6 (RFC 2460) Normative References for Address Family Numbers Since publication of [RFC1700], the IANA has moved to an on-line database for management of the assigned numbers. [IANA] IANA, "Protocol Numbers and Assignment Services", http://www.iana.org/numbers.html [RFC1700] J. Reynolds and J Postel, "ASSIGNED NUMBERS", STD 2, RFC 1700, October 1994. Annex B - Network Address Formats The ESTP command, and the responses to both ESTA and ESTP, contain network addresses. Each network protocol has a required form for representation of its addresses. For informational purposes, the following table shows the formats for the Internet Procotols as of the writing of this document. AF Number Address Format Example --------- -------------- ------- 1 dotted decimal 132.235.1.2 2 IPv6 string 1080::8:800:200C:417A Normative References for Network Address Formats [RFC952] K. Harrenstien, M. Stahl and E. Feinler, "DOD INTERNET HOST TABLE SPECIFICATION", RFC 952, October 1985. [RFC2373] R. Hinden and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998. Annex C - Examples of Use The following examples show typical uses of the ESTA and ESTP Lundberg Expires November 28, 2002 [Page 16] Internet-Draft FTP Data Connection Assurance May 2002 commands detecting an unauthorized connection to the passive socket. The assumption in these examples is that the TCP implementation on the host will establish multiple connections on a passive socket and return them to the implementation in the order established. Thus, a second active connection will succeed without error. Experience shows this assumption holds true for most existing implementations. The examples all use the following IPv4 addresses, which are assumed routable on the example network without address translation. user 192.168.1.2 The user; either actively connecting, passively accepting connections, or not participating in the data transfer. active 172.16.3.4 The Server-FTP process actively connecting (PORT mode). The Server-FTP process will use TCP port 20, as assigned by IANA for this purpose. passive 172.16.5.6 The Server-FTP process passively accepting connections (PASV mode). attacker 10.7.8.9 The attacker actively connecting to the passive socket used in the particular example. The example attacker uses TCP port 20 in a simplistic (and likely successful) attempt to thwart fire-wall filtering rules, and to fool the passive FTP implementation (as well as intrusion detection systems which may be monitoring the traffic) into believing it is an actual Server-FTP implementation. C.1 PORT Mode The user prepares a passive socket and transmits its address to the active Server-DTP. The user's DTP is now listening for connections on that socket. The window for the attacker to connect is now open. user --> active: PORT 192,168,1,2,12,34 The attacker connects to the passive socket. Lundberg Expires November 28, 2002 [Page 17] Internet-Draft FTP Data Connection Assurance May 2002 active --> user: 200 Okay. The Server-DTP is now prepared to actively establish a connection to the specified passive socket. user --> active: ESTA The Server-DTP establishes the specified connection and returns the address of the active socket (the local address on the Server- DTP). The window for the attacker to connect has now closed. active --> user: 225 Connected from (|1|172.16.3.4|20|) The user's DTP accepts the first connection from the passive socket. In this case, the connection from the attacker. It retrieves the active socket address (the remote address) and compares it to the information returned from the Server-FTP process. Seeing a mismatch, the user immediately terminates the established data connection (to the attacker). Note the passive socket, and the established connection from the Server-DTP queued upon it, remain. In most cases, however, since the passive socket is now "tainted," the user will desire to also close the passive socket. To do so, it must first instruct the Server-FTP process to abort the connection. user --> active: ABOR The Server-DTP closes its data connection. active --> user: 226 Connection closed, abort successful. The user may now close the passive socket and proceed with the remainder of its error-recovery process. C.2 PASV Mode The user requests the Server-DTP create a passive socket and report its address. user --> passive: PASV The Server-DTP prepares the requested passive socket. The Server- Lundberg Expires November 28, 2002 [Page 18] Internet-Draft FTP Data Connection Assurance May 2002 DTP is now listening for connections on that socket. The window for the attacker to connect is now open. passive --> user: 227 Listening on 172,16,5,6,78,90 The attacker connects to the passive socket. The user establishes the specified connection and sends the address of the active socket (the address local) to the Server-FTP process. The window for the attacker to connect has now closed. user --> passive: ESTP |1|192.168.1.2|43210| The Server-DTP accepts the first connection from the passive socket. In this case, the connection is from the attacker. It retrieves the active socket address (the remote address) and returns it to the user. passive --> user: 225 Connected to (|1|10.7.8.9|20|) The user compares the address returned with the address assigned to its (local) active socket. Seeing a mismatch, it terminates the data connection prior to issuing a command which would actually transmit data. user --> passive: ABOR The Server-DTP closes the data connection (to the attacker). Note the passive socket remains, as does the user's connection queued upon it. passive --> user: 226 Connection closed, abort successful. The user proceeds with error recovery. In most cases, since the passive socket is now "tainted," the user will close its data connection and instruct the Server-FTP process to close the passive socket and prepare another. C.3 Server-to-Server Mode The user requests the Server-DTP create a passive socket and report its address. user --> passive: PASV Lundberg Expires November 28, 2002 [Page 19] Internet-Draft FTP Data Connection Assurance May 2002 The Server-DTP prepares the requested passive socket. The Server- DTP is now listening for connections on that socket. The window for the attacker to connect is now open. passive --> user: 227 Listening on 172,16,5,6,78,90 The user forwards the passive socket address to the second Server- FTP process. user --> active: PORT 172,16,5,6,78,90 The attacker connects to the passive socket. active --> user: 200 Okay. The second Server-DTP is now prepared to actively establish a connection to the specified passive socket. user --> active: ESTA The second Server-DTP establishes the specified connection and returns the address of the active socket (the local address on the Server-DTP). The window for the attacker to connect has now closed. active --> user: 225 Connected from (|1|172.16.3.4|20|) The user forwards this information to the first Server-FTP process, informing it to accept a passive connection. user --> passive: ESTP |1|172.16.3.4|20| The Server-DTP accepts the first connection from the passive socket. In this case, the connection is from the attacker. It retrieves the active socket address (the remote address) and returns it to the user. passive --> user: 225 Connected to (|1|10.7.8.9|20|) The user compares the address returned with the address provided by the second Server-FTP process. Seeing a mismatch, it proceeds to begin error-recovery by instructing the first Server-DTP to close the data connection (to the attacker). user --> passive: ABOR Lundberg Expires November 28, 2002 [Page 20] Internet-Draft FTP Data Connection Assurance May 2002 The first Server-DTP closes the data connection (to the attacker). Note the passive socket remains, as does the second Server-DTP's connection queued upon it. passive --> user: 226 Connection closed, abort successful. The user proceeds with error recovery. In most cases, since the passive socket is now "tainted," the user will want to instruct the first Server-FTP process to close the passive socket and prepare another. Before it does so, however, it must instruct the second Server-FTP process to close its data connection. user --> active: ABOR The second Server-DTP closes its data connection. active --> user: 226 Connection closed, abort successful. The user may now instruct the first Server-FTP process to close the passive socket and proceed with the remainder of the error- recovery process. Annex D - Implementation Considerations The ESTA and ESTP commands present some interesting possibilities for implementers; three of which are discussed here. Experience shows the implementation of the TCP passive socket, on most hosts, queues incoming connections. While in the queue, the connections are established and simply not being used by the application. In [POSIX], for example, the accept function removes those connections from the queue, making them available to the application. This operation usually involves no network activity; to the remote end-point, the status of the established connection (queued or accepted) is transparent. The formal specifications of the ESTA and ESTP commands indicate the implementation accepts the first connection queued upon the passive socket. There may, however, be several connections queued. One of them can be expected to be the intended connection. D.1 Interactively Finding the Specified Connection In sessions involving a passive Server-DTP, the user could make use of the (probable) behavior of TCP passive sockets in an attempt to locate the desired data connection. Quite simply, after instructing the passive Server-FTP process to Lundberg Expires November 28, 2002 [Page 21] Internet-Draft FTP Data Connection Assurance May 2002 close the data connection (to the attacker), instead of immediately requesting the preparation of a new passive socket, the user could issue another ESTP command. Using this scheme, the user is instructing the passive Server-DTP to step through each connection queued on its passive socket until it (the user) finds one which is acceptable. The danger is that attackers can establish new connections faster than the user can process them interactively. Thus, while this approach is viable, the user must guard against connection floods by imposing a limit (either by time or number of attempts) and proceeding on the basis of the last-accepted, mismatched connection once that limit has been reached. A user, seeking maximum robustness, may implement this approach. The Server-FTP process should provide its own guards against connection flooding, either by using the automatic method outlined next, or by limiting (by time or attempts) the user's repeated use of the ESTP command. D.2 Automatically Finding the Specified Connection The implementer will note that, when using passive mode, the desired address is known prior to accepting a connection from the passive socket. For the user, this address was obtained from the response to the ESTA command. For the passive Server-DTP it was given with the ESTP command. This presents the (rather appealing) possibility of stepping through each connection queued on the passive socket until one with the desired address is located. It has the advantage of not involving any network traffic, as is required when interactively seeking the correct connection, and could more quickly reduce resources used (wasted) by the attacker connections. Implementations should consider this approach. Since this is being done with local operations, it is significantly faster than the interactive approach. Connection floods, however, are still a possibility which must be guarded against. D.3 Using a Common Passive Socket An extension of automatically finding the desired connection is the possibility of using a common passive socket for all data transfers. Lundberg Expires November 28, 2002 [Page 22] Internet-Draft FTP Data Connection Assurance May 2002 If the implementation issues with this approach can be addressed, it would greatly reduce the configuration issues faced by fire-wall administrators, and could significantly enhance both the usability and security of the FTP. Basically, the Server-DTP always has a passive socket prepared, and reports the address of that socket in response to all PASV, LPSV and EPSV commands. Those tempted to implement this approach are strongly cautioned to carefully consider all aspects, some of which are presented here. The discussion, however, is probably incomplete and bears careful analysis and further research by implementers. The most obvious problem is that the implementation needs some means to queue connections already accepted, but not yet matched to sessions by the ESTP command. This could place a significant load on resources, especially when faced with a connection flood, and the total number of such connections possible may be restricted by host limitations. Another problem is that some connections will never be matched. In terms of the passive race condition, they would represent attackers; but those connections could simply be the result of failed sessions. Queue-time limitations and other means might provide the solution to this problem. The appeal of this possibility, however, is so great that it bears further research. If the implementation issues can be properly addressed, whether through protocol enhancements or through implementation guidelines, this could become the preferred mode of use for passive sockets in Server-FTP implementations. Lundberg Expires November 28, 2002 [Page 23] Internet-Draft FTP Data Connection Assurance May 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to The Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by The Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by The Internet Society. Lundberg Expires November 28, 2002 [Page 24]