[12918] in bugtraq
Re: FTP denial of service attack
daemon@ATHENA.MIT.EDU (der Mouse)
Fri Dec 10 12:43:01 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-Id: <199912090514.AAA07866@Twig.Rodents.Montreal.QC.CA>
Date: Thu, 9 Dec 1999 00:14:13 -0500
Reply-To: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
From: der Mouse <mouse@RODENTS.MONTREAL.QC.CA>
X-To: BUGTRAQ@SECURITYFOCUS.COM
To: BUGTRAQ@SECURITYFOCUS.COM
> 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 still can't see how you can use them. Each STOR or RETR (or LIST, or
whatever) uses the most recently specified data connection; there's no
way to use any others. And you can't start transferring and leave it
to finish, either, because once the transfer starts all you can do with
the control connection is wait until the transfer finishes or do the
IP/Synch/ABOR thing (a few other commands are allowed, such as STAT,
but certainly not the whole suite; I suppose you could make a server
recognize them, but it's still not clear how it would work - which
reply goes with which transfer, at a minimum?).
> 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.
Quite aside from requiring a protocol rework, there's no use for it,
except bandwidth-hogging by performing multiple transfers in parallel
rather than serially.
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
