People around the net are all yelling how insecure it is to have writable root FTP directory, if you configure your FTP server with the chroot option (vsftpd won't even run).
I miss the explanation why is it bad?
Could someone expand a little bit more on that topic and explain what are the dangers, how a chroot directory writable by unprivileged users can be exploited?
The attack here is commonly known as the "Roaring Beast" attack; you can read more about it in these bulletins:
In order to use the chroot(2) function, the FTP server must have root privileges. Later, the unprivileged client requests the creation of files within /etc (or /lib) within that chrooted server process. These directories usually contain dynamically loaded libraries and configuration for system libraries like the DNS resolver, user/group name discovery, etc. The client-created files are not in the real /etc/ and /lib directories on the system -- but within the chroot, these client-created files are real.
So the malicious client connects to an FTP server which chroots their process, they create the necessary /lib and /etc directories/files within that chroot, upload a malicious copy of some dynamic libraries, and then ask the server to perform some action that triggers the use of their new dynamic libraries (usually just a directory listing, which leads to using the system functions for user/group discovery, etc). The server process runs that malicious libraries, and because the server might still have root privileges, that malicious library code can then have extra access to do whatever it wants.
Note that /etc and /lib are not the only directories to watch; the issue is more about the assumptions made by system libraries about their file locations in general. Thus different platforms may have other directories to guard.
ProFTPD, for example, now bars the creation of such /etc/ and /lib directories when chrooted, to mitigate such attacks.
/etc/ or /lib/). Think of gethostbyname(3) automatically reading /etc/hosts or /etc/resolv.conf; getpwnam(3) might use NSS, and thus read /etc/nsswitch.conf and related NSS libraries.
Commented
Aug 18, 2017 at 15:13