Bug 197141 - vsftpd 2.0.1 memory leak
vsftpd 2.0.1 memory leak
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vsftpd (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Nagy
: FutureFeature, Patch
Depends On:
Blocks: CVE-2008-2375
  Show dependency treegraph
Reported: 2006-06-28 15:31 EDT by Brandon Poyner
Modified: 2016-07-26 19:46 EDT (History)
5 users (show)

See Also:
Fixed In Version: RHSA-2008-0680
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-24 15:34:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
max_login_fails patch (3.13 KB, patch)
2007-09-20 13:50 EDT, Brandon Poyner
no flags Details | Diff
Patch for RPM spec file (597 bytes, patch)
2007-09-20 13:51 EDT, Brandon Poyner
no flags Details | Diff

  None (edit)
Description Brandon Poyner 2006-06-28 15:31:49 EDT
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):


How reproducible:


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:


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:
Comment 1 Anchor Systems Managed Hosting 2006-08-20 08:28:14 EDT
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.
Comment 2 Brandon Poyner 2006-08-23 10:22:16 EDT
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.

Comment 3 Brian DeFeyter 2007-09-19 23:11:43 EDT
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?
Comment 4 Brandon Poyner 2007-09-20 13:50:49 EDT
Created attachment 201051 [details]
max_login_fails patch
Comment 5 Brandon Poyner 2007-09-20 13:51:50 EDT
Created attachment 201061 [details]
Patch for RPM spec file
Comment 6 Brandon Poyner 2007-09-20 14:06:23 EDT
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
# 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
Comment 8 Martin Nagy 2007-12-03 04:41:05 EST
How about fixing the leak instead? It shouldn't be hard.
Comment 9 Brandon Poyner 2007-12-07 10:37:05 EST
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.
Comment 11 Martin Nagy 2008-02-04 05:02:22 EST
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.
Comment 12 Martin Nagy 2008-02-08 05:50:33 EST
Fix checked in CVS and the new packages were built successfully. This issue
should be resolved in vsftpd-2.0.1-6.el4
Comment 16 errata-xmlrpc 2008-07-24 15:34:45 EDT
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.


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