The ebuild of pure-ftpd compiles with the option: "--with-virtualchroot". This causes a security problem. With this option you can access all files outside of your chroot. Quote from the pure-ftpd FAQ (http://www.pureftpd.org/FAQ): --------------------------------------------------------------------------- * Chrooted users can follow symlinks outside the chroot jail? -> People can create symbolic links to '/' and escape their home directory! There are two chroot implementations in pure-ftpd: - The traditional one, based upon your kernel chroot() system call. This is the default. With that one, symbolic links can only point inside the chroot jail, or they won't be followed. - The 'virtual chroot' implementation. With that feature, users *can* follow all symbolic links, even when they don't point inside the jail. This is very handy to set up directories shared by multiple users. Binary packages are compiled with virtual chroot by default. --------------------------------------------------------------------------- It would be nice to be disable the virtual-chroot with an use-flag. Now the users will have to hack the ebuild. This isn't, IMHO, a desirable situation. Reproducible: Always Steps to Reproduce: 1. emerge pure-ftpd 2. 3. Actual Results: pure-ftpd compiles with the --with-virtualchroot option. Expected Results: Offer me a choice between compiling pure-ftpd with- or without the --with-virtualchroot option.
Looks more like a default config bug (i.e. it works as expected, but it's confusing).
pure-ftpd-1.0.20-r1.ebuild is in portage now, i'll mark it stable tomorow after some more tests. Other arches should follow.
A fix, and so quick, great! I've tested it, and it seems to work fine.
Thx Gustavo. Arches please test and mark stable.
I've done a quick test to verify, that you are unable to escape from your chroot using a link and the test was successful: you couldn't ecape. Stable on ppc64
On irc: jaervosz - HumpBack: you think it is real security issue we should issue an advisory on? Well i really dont know. The older releases had the option to use the insecure virtual-chroots hardcoded in the configure option, and as far as i could find there is no way to deactivate it at runtime. So there could be running systems where the admins think users are locked in the chroot and they are not.
sparc stable.
Users can *not* create symlinks through pure-ftpd. They have to do it through a shell or other means. But if they can do it, they already have access to a non-chrooted environment. The virtual chroot feature is what most users need in order to have shared folders.
>> They have to do it through a shell or other means. But if they can do it, they already have access to a non-chrooted environment. That is incorrect, a user can create a symlink to '/' via ssh while in a chroot. This symlink will lead to the root of the chroot (e.g. /home/chroot/user). If the user than connects to the pure-ftpd the '/' symlink links to the root of the system and not of the chroot.
Stable on alpha.
Sorry for the delay. Stable on ppc.
hppa/ia64 stable
This is fixed, as now we have a (more) secure default. This wasn't a vulnerability (works as advertised) so closing without GLSA. If you disagree feel free to reopen.
