vsftp: why is allow_writeable_chroot=YES a bad idea?

Solution 1:

If the FTP credentials of a user (even a virtual user) with a writeable chroot get compromised, the attacker might conceivably be able to perform a ROARING BEAST ATTACK. To summarise my rough understanding of this attack, it involves exploiting the fact that some C libraries (perhaps including ones used by the FTP server) will look for dynamic libraries that they depend on at hard-coded paths in /etc or other common locations. The attacker uploads evil versions of those dynamic libraries to the /etc within the chroot, then sends a command to the (running-as-root) FTP server that induces it to run some code that loads in that dynamic library from /etc. The attacker's evil code then runs as root. This escalates the attack from a mere compromise of the user's FTP folder to rooting the entire machine.

Having a non-writeable chroot renders this attack impossible (unless you, the sysadmin, have unwisely created writeable folders with names like /etc and /lib within your FTP users' chroot directories).

Solution 2:

The main concern is that it makes dotfiles writable. Depending on your shell, the way login is set up, whether $HOME/.ssh is used, what other services are running and a few other things, this provides a lot more attack surface to abuse, mostly through manipulation of user environment variables. There isn't a comprehensive guide on what and why because that would require knowing the attacks before they happen.

Long story short, for usability, most distributions reference a user's home directory in one way or another and making it writable means those references could potentially be manipulated.