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?
>
> der Mouse
>
> [EMAIL PROTECTED]
> 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
>
>
-->Phillip Susi
[EMAIL PROTECTED]
