14

There are several thousand blog posts about vsftp and allow_writeable_chroot=YES

The common error message:

Fixing 500 OOPS: vsftpd: refusing to run with writable root inside chroot ()

I solved the problem on my server.

But one question remains:

Why is it advisable to use allow_writeable_chroot=NO?

Up to now I only found nebulous arguments like "For security reasons".

What are these "security reasons"?

guettli
  • 3,113
  • 14
  • 59
  • 110
  • 2
    Where is the official documentation for `allow_writeable_chroot`? – guettli Dec 18 '15 at 11:38
  • 1
    Nowhere : https://security.appspot.com/vsftpd.html but you may have an answer there : #vsftpd IRC channel at irc.freenode.net. – Froggiz Dec 18 '15 at 11:46

2 Answers2

7

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).

Mark Amery
  • 677
  • 1
  • 7
  • 24
  • I like to switch the perspective and to look at the world through the eyes of a evil black hat hacker :-) Thank you for the link to the roaring beast attack. Lazy loading of libraries ... then loading from chroot ... nice. – guettli Sep 06 '17 at 10:58
  • Why would vsfrpd load _any_ libraries, evil or not from /etc within a chroot??? – Andrew Savinykh Jun 23 '21 at 09:28
  • @AndrewSavinykh because once you've `chroot`ed the `/etc` within the `chroot` just looks like `/etc` - that's the whole point of `chroot`ing - and the standard mechanism for loading dynamic libraries looks for stuff in `/etc` and `/lib`. Or at least, that's my understanding of the linked post and of https://unix.stackexchange.com/a/22999/29001! – Mark Amery Jun 23 '21 at 09:45
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.

Andrew Domaszek
  • 5,103
  • 1
  • 14
  • 26
  • 1
    .ssh/authorized_keys is not (directly) inside $HOME. A readonly $HOME does not help for this file. And for `.bashrc`: if you are allowed to login into this $HOME, then you can set any environment variable you like interactively. I still don't get it. – guettli Dec 18 '15 at 14:27