On Mon, Jun 13, 2011 at 8:31 PM, Allen Firstenberg <[email protected]> wrote: > First of all - we see the algorithm for PassivePorts is that it creates an > ordered list of ports and attempts to allocate the lowest available port. > It does seem that there is a check to make sure a free port is actually > available, but we're wondering if the port could be held open by a firewall > or client even tho the server thinks its closed. (We will be the first to > admit that we're grasping at straws here, but it would explain some of what > we've seen).
Yes, in TCP/IP there is certainly the possibility of the client and server disagreeing on wether a socket is open or not. What's the actual problem you're seeing? > In researching this, however, we're VERY concerned by the algorithm used. > Any algorithm that offers predictably guessable unsecured open ports seems > like a major security issue - does Apache FTP mitigate this by ensuring that > the same client address is used to connect to both the control and data > ports? Yes, FtpServer has a check for this, but disabled by default. Set the ip-check attribute on the <passive> element to true. (I noted this is missing for our documentation, which I will fix). > Most servers that implement linear allocation seem to always use "next > available" instead of "lowest available" ports. A few even use "randomly > available", which seems like it would be a lot more secure. Is there a > reason either of these were not used? I don't really know since I did not write the passive ports implementation, in any case these seem like any of these algorithms mostly serve as way of slightly postponing the attack on the passive port (where picking the lowest port arguable does the least to postpone). Using something like the IP check or even using a secure data connection and checking that the certificate matches (something FtpServer does not currently support) would seem like a much better solution. All that said, the passive ports algorithm is up for a rewrite (https://issues.apache.org/jira/browse/FTPSERVER-360, https://issues.apache.org/jira/browse/FTPSERVER-264) and any input or code would be more than welcome. > Finally, we noticed that PassivePorts.reserveNextPort() is not synchronized. > Why was this? We do note that it is called from two locations, both > synchronized methods, although it seems like there is still a high > possibility for a race condition here although we didn't dig closely into > the methods in question. Seems like a bug to me, feel free to open an issue. /niklas
