Bug 522141 (CVE-2009-2904)

OpenSSH version 4.8 introduced support for ChrootDirectory configuration option, which allows chrooting of users after successful authentication to a specified directory:

  http://openssh.org/txt/release-4.8

sshd requires strict permissions of the chroot directory and all parent directories, as detailed in the manual pages:

  sshd_config(5)

  This path, and all its components, must be root-owned directories that
  are not writable by any other user or group.

  http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5

OpenSSH version in Red Hat Enterprise Linux 5 (backport of ChrootDirectory was added in 5.4) and Fedora 11 (only testing, at the moment) relaxed this check to allow directories to be owned by the user logging in, to make ChrootDirectory %h setting work more "as expected".  However, it was discovered that this change makes system more vulnerable to attacks using mis-configured chroot directory trees.

Possible attack requires user to be able to create hard links to setuid programs installed on the system out of the chroot.  This actually consists of two requirements:

- user must have non-chroot-ed shell access to the system (e.g. local console access, or do the setup of the chroot directory before ChrootDirectory is enabled for the user)

- target setuid program must be located on the same file system as user's home directory

If the behaviour of the target setuid program is controlled by some configuration file (e.g. PAM configuration files, library), it may use attacker-controlled file instead of the administrator-controlled one and allow user to escalate privileges, when program is executed inside of the chroot.

Other attack vectors may be possible.

Upstream bugreport proposing upstream inclusion of the fix:
  https://bugzilla.mindrot.org/show_bug.cgi?id=1593
  (with upstream stating this is a bad idea)

Article describing the use of ChrootDirectory:
  http://undeadly.org/cgi?action=article&sid=20080220110039