Darren Reed wrote: > 3. The port specification is changed by a command from the > user. PASV falls into this category. PASV changes the server side of the port specification of the data channel. Remember that the port specifiaction in FTP consists of both sides of the connection (not to be confused with the PORT command which only specifies one side: the client side). FTP is a quite odd protocol from a TCP/IP point of view with very special assumptions on port numbers and a different notion of "port specification" than most other protocols. > > All FTP servers I have tried does this. > > And those are which ones ? Having read the RFC, I would counter your > claim and say they're not compliant with rfc959. I hope this isn't > one you've written yourself O:-) I have mostly tried connection management on WU-FTPd based servers, but also a couple of Microsoft NT, OpenVMS and others. Not closing a existing data connection when a PASV command is accepted would be in violation of RFC 959 section 3.2 criteria 3. If in doubt if this is relevant to PASV, see section 3.3. FTP does not support more than one data channel per control channel. This limitation is both in connection management and command structure (syncronous command/reply, not pipelined). If you still don't believe me, use netstat on the FTP server while your exploit it attacking it. The sockets will be stuck in FIN_WAIT_2 because the FTP server has closed it's end of the connection but your exploit code keeps it's end open (in CLOSE_WAIT state), thereby blocking the TCP from fully closing down the socket. Your exploit is a effective DOS on most FTP servers. Best way around it would be for the FTP server to exponentially delay data channel reopen request if the reopen rate is high relative to the amount of sucessful data transfers, and to make sure the host operating system has a timeout for FIN_WAIT_2 (not entirely legal in TCP, but needed today to avoid several DOS cases related to FIN_WAIT_2) -- Henrik Nordstrom
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:19:10 PDT