mailing list archives
Re: FTP denial of service attack
From: phreak () IAG NET (Phillip Susi)
Date: Wed, 8 Dec 1999 23:48:52 -0500
The RFC is somewhat ambiguous in this area, and it is not clear how one
would go about actually doing it, but I belive it does indicate that you
can have multiple data connections as long as you issue a REIN command to
reinitialize the user and IO context before you issue a new PORT or PASV
command. I think it would be nice to be able to have such a feature so
clients that wanted to do that kind of thing wouldn't have to open multiple
control connections each time.
At 01:32 PM 12/7/99 -0500, you wrote:
I have trouble imagining why any ftp daemon *would* support multiple
data connections for any given control connection. RFC 959 speaks of
"the" data connection of an FTP session, and in the absence of any way
to specify which data connection is to be used for a data transfer,
there's no use for multiple such anyway.
Presumably something of the sort could be supported as an extension,
but just doing PASV/connect/PASV/connect/PASV/connect the way the
posted exploit does is not something I would expect would do any damage
(except for, possibly, tying up the whole available range of port
numbers with TIME_WAIT tcbs, an attack that can be launched against
almost any service, if it can be done at all).
Simply issuing PORT/PASV commands over and over without a data transfer
command will simply change the port that will be used for the data transfer
command. What it looks like this code is doing is issuing multiple PASV
commands over and over, and the server simply is not cleaning up the
listening socket when it gets a new command. This is a bug in the server.
I don't know of any ftp clients which make use of this feature
(multiple data channels supported concurrently) as the original ftp
clients were all line-based and only suported one transfer at a time.
As far as I can tell the ftp protocol has no way to name data channels,
so there's no way for *any* ftp client to use multiple concurrent data
channels without opening a separate control connection for each one,
and that this is therefore a simple bug in servers that accept multiple
PASV commands and maintain multiple concurrent data connections for a
single control connection. Am I missing something?
mouse () rodents montreal qc ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Phreak () iag net