Bug 197141
Summary: | vsftpd 2.0.1 memory leak | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 4 | Reporter: | Brandon Poyner <bpoyner> | ||||||
Component: | vsftpd | Assignee: | Martin Nagy <mnagy> | ||||||
Status: | CLOSED ERRATA | QA Contact: | |||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 4.0 | CC: | bdf, hripps, managed, mbarabas, mnagy | ||||||
Target Milestone: | --- | Keywords: | FutureFeature, Patch | ||||||
Target Release: | --- | ||||||||
Hardware: | i686 | ||||||||
OS: | Linux | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | RHSA-2008-0680 | Doc Type: | Enhancement | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2008-07-24 19:34:45 UTC | Type: | --- | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Bug Depends On: | |||||||||
Bug Blocks: | 453376 | ||||||||
Attachments: |
|
Description
Brandon Poyner
2006-06-28 19:31:49 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. 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 |