Bug 483604 - vsftpd not honouring delay_failed_login when userlist active
vsftpd not honouring delay_failed_login when userlist active
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: vsftpd (Show other bugs)
10
All Linux
low Severity medium
: ---
: ---
Assigned To: Jiri Skala
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-02 11:05 EST by Ted Rule
Modified: 2014-11-09 17:31 EST (History)
3 users (show)

See Also:
Fixed In Version: 2.0.7-2.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-06-24 15:44:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for 2.1.0 (522 bytes, patch)
2009-04-12 12:25 EDT, Tomas Hoger
no flags Details | Diff

  None (edit)
Description Ted Rule 2009-02-02 11:05:33 EST
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.
Comment 1 Tomas Hoger 2009-02-03 05:25:19 EST
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?
Comment 2 Martin Nagy 2009-02-03 06:22:06 EST
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.
Comment 3 Martin Nagy 2009-02-03 06:32:23 EST
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.
Comment 4 Ted Rule 2009-02-03 06:33:10 EST
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."
Comment 5 Tomas Hoger 2009-02-03 08:52:26 EST
(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).
Comment 6 Ted Rule 2009-02-09 10:24:01 EST
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.
Comment 7 Tomas Hoger 2009-04-12 12:25:53 EDT
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.
Comment 8 Tomas Hoger 2009-05-25 04:55:58 EDT
Upstream replied this should be added to upcoming 2.1.1.
Comment 9 Tomas Hoger 2009-06-01 08:34:32 EDT
Patch from comment #7 was included upstream in 2.1.1.
Comment 10 Fedora Update System 2009-06-03 03:59:34 EDT
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
Comment 11 Jiri Skala 2009-06-03 04:01:55 EDT
The fix is backported from upstream version 2.1.2 that is in fc11 and rawhide.
Comment 12 Fedora Update System 2009-06-04 17:09:02 EDT
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
Comment 13 Fedora Update System 2009-06-24 15:44:19 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.