[12922] in bugtraq

home help back first fref pref prev next nref lref last post

Re: FTP denial of service attack

daemon@ATHENA.MIT.EDU (Darren Reed)
Fri Dec 10 13:16:09 1999

Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id:  <199912090435.PAA29335@cairo.anu.edu.au>
Date:         Thu, 9 Dec 1999 15:35:59 +1100
Reply-To: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
From: Darren Reed <avalon@COOMBS.ANU.EDU.AU>
X-To:         mouse@RODENTS.MONTREAL.QC.CA
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To:  <199912071832.NAA29675@Twig.Rodents.Montreal.QC.CA> from "der
              Mouse" at Dec 07, 1999 01:32:57 PM

In some mail from der Mouse, sie said:
[...]
> 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?

Just the obvious from an implementation point of view ;) 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.

Darren

home help back first fref pref prev next nref lref last post