Description of problem: There appears to be a small memory leak in vsftpd that shows up when a user fails to authenticate. This small memory leak could lead to a remotely executed ddos. This is due to vsftpd permitting an unlimited number of authentication attempts per tcp connection. Version-Release number of selected component (if applicable): vsftpd-2.0.1-5.EL4.3 How reproducible: very Steps to Reproduce: 1. install vsftpd server and start it 2. for debugging purposes it helps to insert 'nodelay' in the pam_unix.so auth section of pam.d/system-auth. the results are more apparent this way, although an attacker can hold on to one vsftpd connection for weeks on end. 3. start a process to repeatedly attempt logging in to vsftpd with invalid credentials. Short perl example: #!/usr/bin/perl use Net::FTP; $host = "localhost"; $ftp = Net::FTP->new("$host", Debug => 0) or die "Cannot connect to $host: $@"; for ( $i=1 ; ; $i++ ) { $user = "joe"; $passwd = "joenonymous"; $ftp->login("$user","$passwd") or print "Attempt $i: Cannot login as $user: ", $ftp->message; } Actual results: vsftpd process grows in size to hundreds of megabytes. valgrind reports memory leaks when attached to a vsftpd process being attacked. Expected results: vsftpd process to not grow so large. Additional info:
We are also seeing this in vsftpd-2.0.1-5.EL4.5 on x86_64. Due to the many bruteforce password-cracking attempts on the servers running this version of vsftpd, the memory footprint is blowing out to the entire server's available and RAM creating a very real denial of service.
The Changelog for the recently released vsftpd 2.0.5 indicates unlimited login attempts are no longer permitted: - Kick session after a few login fails. Allows IP blocking solutions to be more immediately effective. It does not directly address the memory leak, but by killing the session the memory leak becomes unimportant. It would be very easy to backport, if there is interest I can provide a patch. ftp://vsftpd.beasts.org/users/cevans/untar/vsftpd-2.0.5/Changelog
I am having DoS problems due to running out of memory from this. Any chance we can get RHEL4 updated to vsftpd-2.0.5?
Created attachment 201051 [details] max_login_fails patch
Created attachment 201061 [details] Patch for RPM spec file
Since people are seeing real world DoS problems, I've backported the max_login_fails feature from vsftpd 2.0.5 and provided a patch to the RPM spec file. Steps for building the new RPM for those that need it: # wget http://ftp.redhat.com/pub/redhat/linux/enterprise/4/en/os/i386/SRPMS/vsftpd-2.0.1-5.src.rpm # rpm -Uvh vsftpd-2.0.1-5.src.rpm # cp vsftpd-2.0.1-max_logins.patch /usr/src/redhat/SOURCES # cp vsftpd-2.0.1-spec.patch /usr/src/redhat/SPECS # cd /usr/src/redhat/SPECS # patch < vsftpd-2.0.1-spec.patch # rpmbuild -bb vsftpd.spec The new RPM will be in /usr/src/redhat/<your arch>. The default number of failed login attempts is 3 and can be adjusted by setting max_login_fails in vsftpd.conf.
How about fixing the leak instead? It shouldn't be hard.
For what it's worth, it appears that the memory leak does not exist in Fedora 8's vsftpd. Fixing the memory leak addresses part of the problem, but it would still permit attackers to hold on to one connection. An argument against only fixing the memory leak is for the people who are using utilities such as DenyHosts and fail2ban. These utilities can be used to detect dictionary attackers and put an entry in hosts.deny, which is ineffective if the connection already exists.
Since it is desirable to add the feature of dropping the connection after a number of attempted logins, I will backport the patch from vsftpd 2.0.5 and I won't be fixing the memory leak, so the number of changes is as low as possible.
Fix checked in CVS and the new packages were built successfully. This issue should be resolved in vsftpd-2.0.1-6.el4
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2008-0680.html