Re: FTP denial of service attack

[mouse () RODENTS MONTREAL QC CA (der Mouse)]

> [data-connection-spamming DOS attack against FTP servers]

> ftpd's which limit connections to 1 per user@host or similar may have
> some defense against this, or if they don't support multiple data
> connections open at the same time.

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).

> 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?

                                        der Mouse

                               mouse () rodents montreal qc ca
                     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B