Bug 80458 – net-ftp/pure-ftpd allows accessing of files outside the chroot through a symlink

• Product: Gentoo Security
• Status: RESOLVED FIXED

[Description Marijn Koesen 2005-02-02 06:34:09 UTC]

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.

[Comment 1 Thierry Carrez (RETIRED) 2005-02-02 10:10:50 UTC]

Looks more like a default config bug (i.e. it works as expected, but it's confusing).

[Comment 2 Gustavo Felisberto (RETIRED) 2005-02-02 11:04:02 UTC]

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.

[Comment 3 Marijn Koesen 2005-02-02 12:05:48 UTC]

A fix, and so quick, great!

I've tested it, and it seems to work fine.

[Comment 4 Sune Kloppenborg Jeppesen (RETIRED) 2005-02-02 12:43:38 UTC]

Thx Gustavo.

Arches please test and mark stable.

[Comment 5 Markus Rothe (RETIRED) 2005-02-02 13:15:16 UTC]

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

[Comment 6 Gustavo Felisberto (RETIRED) 2005-02-02 14:03:34 UTC]

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.

[Comment 7 Gustavo Zacarias (RETIRED) 2005-02-03 05:50:35 UTC]

sparc stable.

[Comment 8 Jedi/Sector One 2005-02-04 03:11:52 UTC]

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.

[Comment 9 Marijn Koesen 2005-02-04 03:27:08 UTC]

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

[Comment 10 Bryan Østergaard (RETIRED) 2005-02-04 13:19:44 UTC]

Stable on alpha.

[Comment 11 Michael Hanselmann (hansmi) (RETIRED) 2005-02-04 14:04:19 UTC]

Sorry for the delay. Stable on ppc.

[Comment 12 SpanKY 2005-02-06 03:01:59 UTC]

hppa/ia64 stable

[Comment 13 Thierry Carrez (RETIRED) 2005-02-06 09:22:45 UTC]

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.