Bug 522141 - (CVE-2009-2904) CVE-2009-2904 openssh: possible privilege escalation when using ChrootDirectory setting
CVE-2009-2904 openssh: possible privilege escalation when using ChrootDirecto...
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
: Security
Depends On: 523161 523162
  Show dependency treegraph
Reported: 2009-09-09 11:11 EDT by Tomas Hoger
Modified: 2010-03-30 02:41 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-03-30 02:41:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Tomas Hoger 2009-09-09 11:11:16 EDT
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 10:09:25 EDT
Links to few older discussions on ChrootDirectory security checks on the upstream openssh-unix-dev mailinglist:

Comment 3 Mark J. Cox (Product Security) 2009-09-30 11:02:25 EDT
Removing embargo, making public
Comment 4 errata-xmlrpc 2009-09-30 11:11:02 EDT
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 02:41:45 EDT
openssh-5.2p1-6.fc11 has been submitted as an update for Fedora 11.
Comment 7 Fedora Update System 2010-03-29 22:17:40 EDT
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.