Bug 197141 - vsftpd 2.0.1 memory leak
Summary: vsftpd 2.0.1 memory leak
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: vsftpd   
(Show other bugs)
Version: 4.0
Hardware: i686
OS: Linux
Target Milestone: ---
: ---
Assignee: Martin Nagy
QA Contact:
Keywords: FutureFeature, Patch
Depends On:
Blocks: CVE-2008-2375
TreeView+ depends on / blocked
Reported: 2006-06-28 19:31 UTC by Brandon Poyner
Modified: 2016-07-26 23:46 UTC (History)
5 users (show)

Fixed In Version: RHSA-2008-0680
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-07-24 19:34:45 UTC
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 17:50 UTC, Brandon Poyner
no flags Details | Diff
Patch for RPM spec file (597 bytes, patch)
2007-09-20 17:51 UTC, Brandon Poyner
no flags Details | Diff

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2008:0680 normal SHIPPED_LIVE Moderate: vsftpd security and bug fix update 2008-07-24 16:38:54 UTC

Description Brandon Poyner 2006-06-28 19:31:49 UTC
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 12:28:14 UTC
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 14:22:16 UTC
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-20 03:11:43 UTC
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 17:50:49 UTC
Created attachment 201051 [details]
max_login_fails patch

Comment 5 Brandon Poyner 2007-09-20 17:51:50 UTC
Created attachment 201061 [details]
Patch for RPM spec file

Comment 6 Brandon Poyner 2007-09-20 18:06:23 UTC
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 09:41:05 UTC
How about fixing the leak instead? It shouldn't be hard.

Comment 9 Brandon Poyner 2007-12-07 15:37:05 UTC
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 10:02:22 UTC
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 10:50:33 UTC
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 19:34:45 UTC
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.