[12920] in bugtraq
Re: FTP denial of service attack
daemon@ATHENA.MIT.EDU (der Mouse)
Fri Dec 10 13:01:38 1999
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
Message-Id: <199912090506.AAA07828@Twig.Rodents.Montreal.QC.CA>
Date: Thu, 9 Dec 1999 00:06:37 -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
>> 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,
> It makes sense that (if the ftp server supports is) for a second
> file, for which I've made a second connection, to come down that
> stream, etc. The connections aren't named directly because there is
> no need to. The single order of operations within the FTP protocol
> provides some assurance that file request A goes with connection a,
> etc.
Now I'm *sure* I'm missing something.
Okay. Send PASV or PORT. Send STOR or RETR. Bits start flowing over
the data connection.
Now, your control connection is, per the protocol, out of commission
until the transfer finishes - all you can do with it is SYNCH/IP and
ABOR. How are you going to initiate a second transfer? Even if you
had previously done another PASV/PORT?
Or are you proposing to revise the protocol in some way? If so, at
least make it clear you're talking about a revised protocol, hmmm?
der Mouse
mouse@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
