inets,ftp: Break out FTP from inets

- Created initial directory structure for the FTP application.
- Updated inets Makefiles to not include FTP related modules.
- Remove ftp code from inets
- Implement backward compatibility layer for FTP
- Add inets_ftp_wrapper
- Fix failing TCs

Change-Id: I120ec5bdef0c3df4cee2d7880db2aec581505bc4

1 files changed, 451 insertions, 0 deletions

diff --git a/lib/ftp/doc/archive/rfc2577.txt b/lib/ftp/doc/archive/rfc2577.txt
new file mode 100644
index 0000000000..83ba203130
--- /dev/null
+++ b/lib/ftp/doc/archive/rfc2577.txt
@@ -0,0 +1,451 @@
+
+
+
+
+
+
+Network Working Group                                          M. Allman
+Request for Comments: 2577                  NASA Glenn/Sterling Software
+Category: Informational                                     S. Ostermann
+                                                         Ohio University
+                                                                May 1999
+
+
+                      FTP Security Considerations
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The specification for the File Transfer Protocol (FTP) contains a
+   number of mechanisms that can be used to compromise network security.
+   The FTP specification allows a client to instruct a server to
+   transfer files to a third machine.  This third-party mechanism, known
+   as proxy FTP, causes a well known security problem.  The FTP
+   specification also allows an unlimited number of attempts at entering
+   a user's password.  This allows brute force "password guessing"
+   attacks.  This document provides suggestions for system
+   administrators and those implementing FTP servers that will decrease
+   the security problems associated with FTP.
+
+1   Introduction
+
+   The File Transfer Protocol specification (FTP) [PR85] provides a
+   mechanism that allows a client to establish an FTP control connection
+   and transfer a file between two FTP servers.  This "proxy FTP"
+   mechanism can be used to decrease the amount of traffic on the
+   network; the client instructs one server to transfer a file to
+   another server, rather than transferring the file from the first
+   server to the client and then from the client to the second server.
+   This is particularly useful when the client connects to the network
+   using a slow link (e.g., a modem).  While useful, proxy FTP provides
+   a security problem known as a "bounce attack" [CERT97:27].  In
+   addition to the bounce attack, FTP servers can be used by attackers
+   to guess passwords using brute force.
+
+
+
+
+
+Allman & Ostermann           Informational                      [Page 1]
+
+RFC 2577              FTP Security Considerations               May 1999
+
+
+   This document does not contain a discussion of FTP when used in
+   conjunction with strong security protocols, such as IP Security.
+   These security concerns should be documented, however they are out of
+   the scope of this document.
+
+   This paper provides information for FTP server implementers and
+   system administrators, as follows.  Section 2 describes the FTP
+   "bounce attack".  Section 3 provides suggestions for minimizing the
+   bounce attack.  Section 4 provides suggestions for servers which
+   limit access based on network address.  Section 5 provides
+   recommendations for limiting brute force "password guessing" by
+   clients.  Next, section 6 provides a brief discussion of mechanisms
+   to improve privacy.  Section 7 provides a mechanism to prevent user
+   identity guessing.  Section 8 discusses the practice of port
+   stealing.  Finally, section 9 provides an overview of other FTP
+   security issues related to software bugs rather than protocol issues.
+
+2   The Bounce Attack
+
+   The version of FTP specified in the standard [PR85] provides a method
+   for attacking well known network servers, while making the
+   perpetrators difficult to track down.  The attack involves sending an
+   FTP "PORT" command to an FTP server containing the network address
+   and the port number of the machine and service being attacked.  At
+   this point, the original client can instruct the FTP server to send a
+   file to the service being attacked.  Such a file would contain
+   commands relevant to the service being attacked (SMTP, NNTP, etc.).
+   Instructing a third party to connect to the service, rather than
+   connecting directly, makes tracking down the perpetrator difficult
+   and can circumvent network-address-based access restrictions.
+
+   As an example, a client uploads a file containing SMTP commands to an
+   FTP server.  Then, using an appropriate PORT command, the client
+   instructs the server to open a connection to a third machine's SMTP
+   port.  Finally, the client instructs the server to transfer the
+   uploaded file containing SMTP commands to the third machine.  This
+   may allow the client to forge mail on the third machine without
+   making a direct connection.  This makes it difficult to track
+   attackers.
+
+3   Protecting Against the Bounce Attack
+
+   The original FTP specification [PR85] assumes that data connections
+   will be made using the Transmission Control Protocol (TCP) [Pos81].
+   TCP port numbers in the range 0 - 1023 are reserved for well known
+   services such as mail, network news and FTP control connections
+   [RP94].  The FTP specification makes no restrictions on the TCP port
+   number used for the data connection.  Therefore, using proxy FTP,
+
+
+
+Allman & Ostermann           Informational                      [Page 2]
+
+RFC 2577              FTP Security Considerations               May 1999
+
+
+   clients have the ability to tell the server to attack a well known
+   service on any machine.
+
+   To avoid such bounce attacks, it is suggested that servers not open
+   data connections to TCP ports less than 1024.  If a server receives a
+   PORT command containing a TCP port number less than 1024, the
+   suggested response is 504 (defined as "Command not implemented for
+   that parameter" by [PR85]).  Note that this still leaves non-well
+   known servers (those running on ports greater than 1023) vulnerable
+   to bounce attacks.
+
+   Several proposals (e.g., [AOM98] and [Pis94]) provide a mechanism
+   that would allow data connections to be made using a transport
+   protocol other than TCP.  Similar precautions should be taken to
+   protect well known services when using these protocols.
+
+   Also note that the bounce attack generally requires that a
+   perpetrator be able to upload a file to an FTP server and later
+   download it to the service being attacked.  Using proper file
+   protections will prevent this behavior.  However, attackers can also
+   attack services by sending random data from a remote FTP server which
+   may cause problems for some services.
+
+   Disabling the PORT command is also an option for protecting against
+   the bounce attack.  Most file transfers can be made using only the
+   PASV command [Bel94].  The disadvantage of disabling the PORT command
+   is that one loses the ability to use proxy FTP, but proxy FTP may not
+   be necessary in a particular environment.
+
+4   Restricted Access
+
+   For some FTP servers, it is desirable to restrict access based on
+   network address.  For example, a server might want to restrict access
+   to certain files from certain places (e.g., a certain file should not
+   be transferred out of an organization).  In such a situation, the
+   server should confirm that the network address of the remote hosts on
+   both the control connection and the data connection are within the
+   organization before sending a restricted file.  By checking both
+   connections, a server is protected against the case when the control
+   connection is established with a trusted host and the data connection
+   is not.  Likewise, the client should verify the IP address of the
+   remote host after accepting a connection on a port opened in listen
+   mode to verify that the connection was made by the expected server.
+
+   Note that restricting access based on network address leaves the FTP
+   server vulnerable to "spoof" attacks.  In a spoof attack, for
+   example, an attacking machine could assume the host address of
+   another machine inside an organization and download files that are
+
+
+
+Allman & Ostermann           Informational                      [Page 3]
+
+RFC 2577              FTP Security Considerations               May 1999
+
+
+   not accessible from outside the organization.  Whenever possible,
+   secure authentication mechanisms should be used, such as those
+   outlined in [HL97].
+
+5   Protecting Passwords
+
+   To minimize the risk of brute force password guessing through the FTP
+   server, it is suggested that servers limit the number of attempts
+   that can be made at sending a correct password.  After a small number
+   of attempts (3-5), the server should close the control connection
+   with the client.  Before closing the control connection the server
+   must send a return code of 421 ("Service not available, closing
+   control connection." [PR85]) to the client.  In addition, it is
+   suggested that the server impose a 5 second delay before replying to
+   an invalid "PASS" command to diminish the efficiency of a brute force
+   attack.  If available, mechanisms already provided by the target
+   operating system should be used to implement the above suggestions.
+
+   An intruder can subvert the above mechanisms by establishing
+   multiple, parallel control connections to a server.  To combat the
+   use of multiple concurrent connections, the server could either limit
+   the total number of control connections possible or attempt to detect
+   suspicious activity across sessions and refuse further connections
+   from the site.  However, both of these mechanisms open the door to
+   "denial of service" attacks, in which an attacker purposely initiates
+   the attack to disable access by a valid user.
+
+   Standard FTP [PR85] sends passwords in clear text using the "PASS"
+   command.  It is suggested that FTP clients and servers use alternate
+   authentication mechanisms that are not subject to eavesdropping (such
+   as the mechanisms being developed by the IETF Common Authentication
+   Technology Working Group [HL97]).
+
+6   Privacy
+
+   All data and control information (including passwords) is sent across
+   the network in unencrypted form by standard FTP [PR85].  To guarantee
+   the privacy of the information FTP transmits, a strong encryption
+   scheme should be used whenever possible.  One such mechanism is
+   defined in [HL97].
+
+7   Protecting Usernames
+
+   Standard FTP [PR85] specifies a 530 response to the USER command when
+   the username is rejected.  If the username is valid and a password is
+   required FTP returns a 331 response instead.  In order to prevent a
+   malicious client from determining valid usernames on a server, it is
+   suggested that a server always return 331 to the USER command and
+
+
+
+Allman & Ostermann           Informational                      [Page 4]
+
+RFC 2577              FTP Security Considerations               May 1999
+
+
+   then reject the combination of username and password for an invalid
+   username.
+
+8   Port Stealing
+
+   Many operating systems assign dynamic port numbers in increasing
+   order.  By making a legitimate transfer, an attacker can observe the
+   current port number allocated by the server and "guess" the next one
+   that will be used.  The attacker can make a connection to this port,
+   thus denying another legitimate client the ability to make a
+   transfer.  Alternatively, the attacker can steal a file meant for a
+   legitimate user.  In addition, an attacker can insert a forged file
+   into a data stream thought to come from an authenticated client.
+   This problem can be mitigated by making FTP clients and servers use
+   random local port numbers for data connections, either by requesting
+   random ports from the operating system or using system dependent
+   mechanisms.
+
+9   Software-Base Security Problems
+
+   The emphasis in this document is on protocol-related security issues.
+   There are a number of documented FTP security-related problems that
+   are due to poor implementation as well.  Although the details of
+   these types of problems are beyond the scope of this document, it
+   should be pointed out that the following FTP features has been abused
+   in the past and should be treated with great care by future
+   implementers:
+
+   Anonymous FTP
+
+      Anonymous FTP refers to the ability of a client to connect to an
+      FTP server with minimal authentication and gain access to public
+      files.  Security problems arise when such a user can read all
+      files on the system or can create files. [CERT92:09] [CERT93:06]
+
+   Remote Command Execution
+
+      An optional FTP extension, "SITE EXEC", allows clients to execute
+      arbitrary commands on the server.  This feature should obviously
+      be implemented with great care.  There are several documented
+      cases of the FTP "SITE EXEC" command being used to subvert server
+      security [CERT94:08] [CERT95:16]
+
+   Debug Code
+
+      Several previous security compromises related to FTP can be
+      attributed to software that was installed with debugging features
+      enabled [CERT88:01].
+
+
+
+Allman & Ostermann           Informational                      [Page 5]
+
+RFC 2577              FTP Security Considerations               May 1999
+
+
+   This document recommends that implementors of FTP servers with these
+   capabilities review all of the CERT advisories for attacks on these
+   or similar mechanisms before releasing their software.
+
+10  Conclusion
+
+   Using the above suggestions can decrease the security problems
+   associated with FTP servers without eliminating functionality.
+
+11  Security Considerations
+
+   Security issues are discussed throughout this memo.
+
+Acknowledgments
+
+   We would like to thank Alex Belits, Jim Bound, William Curtin, Robert
+   Elz, Paul Hethmon, Alun Jones and Stephen Tihor for their helpful
+   comments on this paper.  Also, we thank the FTPEXT WG members who
+   gave many useful suggestions at the Memphis IETF meeting.
+
+References
+
+   [AOM98]     Allman, M., Ostermann, S. and C. Metz, "FTP Extensions
+               for IPv6 and NATs", RFC 2428, September 1998.
+
+   [Bel94]     Bellovin. S., "Firewall-Friendly FTP", RFC 1579, February
+               1994.
+
+   [CERT88:01] CERT Advisory CA-88:01. ftpd Vulnerability. December,
+               1988 ftp://info.cert.org/pub/cert_advisories/
+
+   [CERT92:09] CERT Advisory CA-92:09. AIX Anonymous FTP Vulnerability.
+               April 27, 1992. ftp://info.cert.org/pub/cert_advisories/
+
+   [CERT93:06] CERT Advisory CA-93:06. Wuarchive ftpd Vulnerability.
+               September 19,1997
+               ftp://info.cert.org/pub/cert_advisories/
+
+   [CERT94:08] CERT Advisory CA-94:08. ftpd Vulnerabilities. September
+               23, 1997.  ftp://info.cert.org/pub/cert_advisories/
+
+   [CERT95:16] CERT Advisory CA-95:16. wu-ftpd Misconfiguration
+               Vulnerability.  September 23, 1997
+               ftp://info.cert.org/pub/cert_advisories/
+
+   [CERT97:27] CERT Advisory CA-97.27. FTP Bounce.  January 8, 1998.
+               ftp://info.cert.org/pub/cert_advisories/
+
+
+
+
+Allman & Ostermann           Informational                      [Page 6]
+
+RFC 2577              FTP Security Considerations               May 1999
+
+
+   [HL97]      Horowitz, M. and S. Lunt, "FTP Security Extensions", RFC
+               2228, October 1997.
+
+   [Pis94]     Piscitello, D., "FTP Operation Over Big Address Records
+               (FOOBAR), RFC 1639, June 1994.
+
+   [Pos81]     Postel, J., "Transmission Control Protocol", STD 7, RFC
+               793, September 1981.
+
+   [PR85]      Postel, J. and J. Reynolds, "File Transfer Protocol
+               (FTP)", STD 9, RFC 959, October 1985.
+
+   [RP94]      Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
+               RFC 1700, October 1994.  See also:
+               http://www.iana.org/numbers.html
+
+Authors' Addresses
+
+   Mark Allman
+   NASA Glenn Research Center/Sterling Software
+   21000 Brookpark Rd.  MS 54-2
+   Cleveland, OH  44135
+
+   EMail: [email protected]
+
+
+   Shawn Ostermann
+   School of Electrical Engineering and Computer Science
+   Ohio University
+   416 Morton Hall
+   Athens, OH  45701
+
+   EMail: [email protected]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman & Ostermann           Informational                      [Page 7]
+
+RFC 2577              FTP Security Considerations               May 1999
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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 DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Allman & Ostermann           Informational                      [Page 8]
+