Why is the chroot_local_user of vsftpd insecure?

Solution 1:

Check here for VSFTPD's FAQ for the answer your looking for. Below is the important excerpt that I think will answer your question.

Q) Help! What are the security implications referred to in the "chroot_local_user" option?

A) Firstly note that other ftp daemons have the same implications. It is a generic problem. The problem isn't too severe, but it is this: Some people have FTP user accounts which are not trusted to have full shell access. If these accounts can also upload files, there is a small risk. A bad user now has control of the filesystem root, which is their home directory. The ftp daemon might cause some config file to be read - e.g. /etc/some_file. With chroot(), this file is now under the control of the user. vsftpd is careful in this area. But, the system's libc might want to open locale config files or other settings...

Solution 2:

The problem is that you can't both use local accounts and also disable those accounts from shell login. If you set their login shell to /bin/nologin, it won't let you login with vsftpd either.

A better and more secure FTP daemon would be Pure-ftpd. Look it up, it's available from the EPEL repository, and it allows to create virtual users. The server uses a common user/group to set all permissions for the home folders of the users and "maps" the virtual users to that user when it logs in to deal with permissions. That's more secure, and you don't have to deal with openssh login security.

Pure-ftpd also supports a whole lot of features such as quotas, ratios, and such. Much better than vsftpd.

Here's a simple tutorial on how to install it and configure a basic virtual user: http://blog.namran.net/2011/05/04/how-to-setup-virtual-ftp-server-using-pure-ftpd-in-centos/

If you read the full doc (which you should) you'll know that the -d switch when creating the virtual user is an auto-chroot to that directory for that user.

Solution 3:

When chroot’ed to /some/dir/, the filesystem becomes effectively confined to that directory. Thus, any program attempting to open/etc/some_file effectively opens /some/dir/etc/some_file.

When /some/dir/ is writable, a malicious user can insert a maliciously crafted /some/dir/etc/some_file into it.

The resulting degree of insecurity depends on the underlying software being aware of chroot’ing or not. vsFTPd surely is (as mentioned in the FAQ above), but some library underneath may not.