The keyword is "for several years", and CERT now has acted. But back
to non-organizational problems to be ahead of them as usual.
A similar weakness in the FTP protocol involves the passive transfer
mode, which is the opposite of the active one, about which the above
advisory was.
Let's examine a hypothetical FTP session:
$ telnet ftp ftp
Trying 127.0.0.3...
Connected to ftp.
Escape character is '^]'.
220 you have to log in.
user someuser
331 i need your password.
pass pass
230 you seem to be welcome.
pasv
227 Passive mode OK (127,0,0,3,197,9)
list
...
And the server is now waiting for a connection to port 50441, and
(about the same vein than with the PORT insecurity) it accepts mostly
any client connecting to it and sends the data to it.
The problem is that this is all after authenticating the user, so
anyone could have anyones data, even if it needs one time passwords,
and so on.
The only hope to avoid this is just hoping that's a too small chance to
get to the server before the attacker, since there is a time window,
and the port number is also a secret. (Un)fortunately, there are only
65536 ports, and many servers schedule port numbers sequentially. Now,
one only needs to be so lucky to race someone with a passive
connection.
The other part of the problem is that most of the browsers (maybe
recognizing the insecurity of the active ftp, and the easeness of
implementation, and for the sake of working through firewalls) uses
passive ftp, so it's not that hard to find a passive connection.
Theoretically, this attack is much harder to exploit, but the
consequences are pretty serious. It's possible to fetch anyones file
if she's using passive ftp connections (i.e. most browsers), even if
she used strong authentication like one time passwords with plain old
ftp.
The trick is simply to telnet randomserver.isp randomport, and you have
a chance of getting someones sensitive data. You'll have higher
chances if the server is more busy, is farther from the client, or you
tried a passive connection to fetch the current port number. Also with
unix ftp clients, the attacked person simply sees this success as an
empty directory, nothing suspicious. Sometimes, the server logs do not
even show the attackers IP address, just as if the client fetched the
file successfully.
Avoidance: it might be fruitful to reduce the chances of success by
randomizing the port numbers used by the server, but that's pretty
unuseful in itself. The other is a similar check for the data
connection's client ip address, it needs to be the same as the control
connections client. And, of course, never use ftp for anything
private.
-- Janos - Don't worry, my address is real. I'm just bored of spam.