Bug 522141 (CVE-2009-2904) - CVE-2009-2904 openssh: possible privilege escalation when using ChrootDirectory setting
Summary: CVE-2009-2904 openssh: possible privilege escalation when using ChrootDirecto...
Alias: CVE-2009-2904
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 523161 523162
TreeView+ depends on / blocked
Reported: 2009-09-09 15:11 UTC by Tomas Hoger
Modified: 2019-09-29 12:32 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2010-03-30 06:41:39 UTC

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:1470 0 normal SHIPPED_LIVE Moderate: openssh security update 2009-09-30 15:10:59 UTC

Description Tomas Hoger 2009-09-09 15:11:16 UTC
OpenSSH version 4.8 introduced support for ChrootDirectory configuration option, which allows chrooting of users after successful authentication to a specified directory:


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


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


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:
  (with upstream stating this is a bad idea)

Article describing the use of ChrootDirectory:

Comment 2 Tomas Hoger 2009-09-16 14:09:25 UTC
Links to few older discussions on ChrootDirectory security checks on the upstream openssh-unix-dev mailinglist:


Comment 3 Mark J. Cox 2009-09-30 15:02:25 UTC
Removing embargo, making public

Comment 4 errata-xmlrpc 2009-09-30 15:11:02 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 5

Via RHSA-2009:1470 https://rhn.redhat.com/errata/RHSA-2009-1470.html

Comment 6 Fedora Update System 2010-03-29 06:41:45 UTC
openssh-5.2p1-6.fc11 has been submitted as an update for Fedora 11.

Comment 7 Fedora Update System 2010-03-30 02:17:40 UTC
openssh-5.2p1-6.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.