mailing list archives
Re: FTP denial of service attack
From: avalon () COOMBS ANU EDU AU (Darren Reed)
Date: Wed, 8 Dec 1999 15:20:14 +1100
In some mail from Henrik Nordstrom, sie said:
Darren Reed wrote:
3. The port specification is changed by a command from the
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.
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).
Ok, readers excuse me for a second. Section 3.3 reads as follows:
3.3. DATA CONNECTION MANAGEMENT
Default Data Connection Ports: All FTP implementations must
support use of the default data connection ports, and only the
User-PI may initiate the use of non-default ports.
Negotiating Non-Default Data Ports: The User-PI may specify a
non-default user side data port with the PORT command. The
User-PI may request the server side to identify a non-default
server side data port with the PASV command. Since a connection
is defined by the pair of addresses, either of these actions is
enough to get a different data connection, still it is permitted
to do both commands to use new ports on both ends of the data
Reuse of the Data Connection: When using the stream mode of data
transfer the end of the file must be indicated by closing the
connection. This causes a problem if multiple files are to be
transfered in the session, due to need for TCP to hold the
connection record for a time out period to guarantee the reliable
communication. Thus the connection can not be reopened at once.
There are two solutions to this problem. The first is to
negotiate a non-default port. The second is to use another
A comment on transfer modes. The stream transfer mode is
inherently unreliable, since one can not determine if the
connection closed prematurely or not. The other transfer modes
(Block, Compressed) do not close the connection to indicate the
end of file. They have enough FTP encoding that the data
connection can be parsed to determine the end of the file.
Thus using these modes one can leave the data connection open
for multiple file transfers.
We don't want to reuse a connection.
Where does it say only one at a time ?
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.
Different servers behave in different ways, it would seem. Definately
some *don't* close the first data connection before opening a second.
Re: FTP denial of service attack Theo de Raadt (Dec 08)
Re: FTP denial of service attack Gregory A Lundberg (Dec 10)
RSAREF2 buffer overflow patch Gerardo Richarte (Dec 11)
Re: new IE5 remote exploit Shane Hird (Dec 07)
NT WinLogon VM contains plaintext password visible in admin mode Robert Horvick (Dec 07)
[Debian] New version of sendmail released Aleph One (Dec 07)
The money: protocol in Internet Explorer Richard M. Smith (Dec 20)
- Re: FTP denial of service attack, (continued)