16

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"?

Improve this question
2
  • 2
    Where is the official documentation for allow_writeable_chroot?
    – guettli
    Dec 18, 2015 at 11:38
  • 1
    Nowhere : security.appspot.com/vsftpd.html but you may have an answer there : #vsftpd IRC channel at irc.freenode.net.
    – Froggiz
    Dec 18, 2015 at 11:46

2 Answers 2

Reset to default
11

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

Improve this answer
3
  • 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 6, 2017 at 10:58
  • Why would vsfrpd load any libraries, evil or not from /etc within a chroot???
    – Andrew Savinykh
    Jun 23, 2021 at 9:28
  • @AndrewSavinykh because once you've chrooted the /etc within the chroot just looks like /etc - that's the whole point of chrooting - 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 unix.stackexchange.com/a/22999/29001!
    – Mark Amery
    Jun 23, 2021 at 9: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.

Improve this answer
1
  • 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, 2015 at 14:27

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .