Description of problem: vsftpd fails to delay a response to a bad password if an explicit userlist is enabled with "userlist_deny=NO" and userlist_file=<file list of permitted users> This causes a partial DoS by allowing an attacker to continuously bombard a server with bad logins without being suitably throttled by the delay_failed_login option. Version-Release number of selected component (if applicable): vsftpd-2.0.7-1.fc10.i386 How reproducible: Disable anonymous login permissions. Enable permitted userlist with userlist_deny=NO Create a suitable userlist_file containing a single test user Set delay_failed_login to 3 seconds Login with the test user and correct password - Ok. Attempt to login with test user and bad password - Ok pauses for 3 seconds.. Attempt to login with any other username - NOT Ok. Immediate error. Additional info: The general problem here is that vsftpd only enforces the delay_failed_login AFTER consulting pam with the password. If the username is found to be invalid by comparison with the userlist_file prior to handoff to pam, it immediately errors. The problem came to light when we saw a flood of attempted anonymous logins from a Browser to a non-anonymous FTP Server. Despite the presence of the delay_failed_login timeout, the log filled with dozens of errors per-second. This was made worse by the browser not honouring the error code from the server, and sending multiple USER commands along the same TCP socket. A partial workround is to add "anonymous" to the userlist_file. Because this doesn't exist as a real user in /etc/passwd, it will effectively cause delay_failed_login to be invoked when a Browser attempts an anonymous login, but this is hardly a complete fix as any other username which is not listed in the userlist_file can also causes a partial DoS. The problem was originally spotted on a CentOS5.2 box, and seems to apply to all version of vsftpd on all currrent RedHat Enterprise and Fedora distros.
delay_failed_login was probably more meant as anti password brute forcing measure, rather than DoS protection. DoS here does not seem much worse than repeated connects / disconnects without an authentication attempt. Jiri, Martin, can you check with upstream if this issue is known to them and whether they plan to address this?
Hi, from the code, I can see that this is intentional. Furthermore, from the vsftpd.conf man page: userlist_enable ...If a user tries to log in using a name in this file, they will be denied before they are asked for a password. This may be useful in preventing cleartext passwords being transmitted. So this is clearly a feature.
Ah, please disregard my previous comment, I was confused there for a bit. Still, I agree with Tomas that this isn't really a serious issue, and that the reason there is a delay is to make password guessing harder.
I should have mentioned yesterday that this "bug" highlights a problem with Firefox( 3.0.5 ) and possibly lots of other FTP Browsers because use of userlist_enable causes vsftpd to issue a "530 Permission denied" in response to a bad USER command rather in response to PASS. Firefox ignores the first 530, issuing a PASS command which gives "503 Login with USER first". This continues to repeat at high speed. If the FTP Server always processed the PASS command and didn't issue the "530 Permission denied" until after processing a PASS command, then the browser would correctly assume that it can't login, and not retry. For example: Jan 30 14:22:19 hostname vsftpd: Fri Jan 30 14:22:19 2009 [pid 31208] FTP command: Client "1.2.3.4", "PASS <password>" Jan 30 14:22:19 hostname vsftpd: Fri Jan 30 14:22:19 2009 [pid 31208] FTP response: Client "1.2.3.4", "503 Login with USER first." Jan 30 14:22:19 hostname vsftpd: Fri Jan 30 14:22:19 2009 [pid 31208] FTP command: Client "1.2.3.4", "USER anonymous" Jan 30 14:22:19 hostname vsftpd: Fri Jan 30 14:22:19 2009 [pid 31208] [anonymous] FTP response: Client "1.2.3.4", "530 Permission denied." Jan 30 14:22:19 hostname vsftpd: Fri Jan 30 14:22:19 2009 [pid 31208] FTP command: Client "1.2.3.4", "PASS <password>" Jan 30 14:22:19 hostname vsftpd: Fri Jan 30 14:22:19 2009 [pid 31208] FTP response: Client "1.2.3.4", "503 Login with USER first." Jan 30 14:22:19 hostname vsftpd: Fri Jan 30 14:22:19 2009 [pid 31208] FTP command: Client "1.2.3.4", "USER anonymous" Jan 30 14:22:19 hostname vsftpd: Fri Jan 30 14:22:19 2009 [pid 31208] [anonymous] FTP response: Client "1.2.3.4", "530 Permission denied."
(In reply to comment #4) > I should have mentioned yesterday that this "bug" highlights a problem with > Firefox( 3.0.5 ) and possibly lots of other FTP Browsers because use of > userlist_enable causes vsftpd to issue a "530 Permission denied" in response > to a bad USER command rather in response to PASS. [ ... ] > If the FTP Server always processed the PASS command and didn't issue > the "530 Permission denied" until after processing a PASS command, then > the browser would correctly assume that it can't login, and not retry. No, sending "Permission denied" error is the intended feature Martin mentioned above in comment #2. As described by the man page, it is supposed to stop FTP client before password is sent over the wire. So there is a mis-behaving client here to blame. delay_failed_login should probably be honoured even when userlist is in use, but it won't resolve the broken client problem, rather only slow down the amount of retries. From a quick look into RFC 959, 530 is a valid reply to USER command (section 5.4).
I've since found that the source of my original problem was not a broken FTP Client engine in Firefox as I had suspected, but rather a broken FTP Application Layer Firewall in a Cisco PIX. It seems that the PIX erroneously translates "530 Permission denied" into "331 Permission denied", so we get this scenario when Client and Server have an intervening PIX: Client sends USER anonymous, Server returns 530 Permission denied. Client sees 331 Permission denied, which is the same error code as would be seen if the server was asking for a password, i.e. "331 Please specify the password." Client sends PASS password Server returns "503 Login with USER first" Client obeys and retries with USER I still feel it would be logical to get vsftpd to honour delay_failed_login before returning "530 Permission denied" in response to an invalid USER command, but the PIX issue is more fundamental anyway, so I'm going to live with adding anonymous to the userlist_file for the time being.
Created attachment 339246 [details] Patch for 2.1.0 It seems that fix for 2.1.0 is one-liner, 2.0.x seems to need a little more. Let see if there's a reason why upstream does not do this already.
Upstream replied this should be added to upcoming 2.1.1.
Patch from comment #7 was included upstream in 2.1.1.
vsftpd-2.0.7-2.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/vsftpd-2.0.7-2.fc10
The fix is backported from upstream version 2.1.2 that is in fc11 and rawhide.
vsftpd-2.0.7-2.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update vsftpd'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-5821
vsftpd-2.0.7-2.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.