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...
Status: CLOSED ERRATA
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,source=redhat,reporte...
: Security
Depends On: 523161 523162
Blocks:
  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:
Environment:
Last Closed: 2010-03-30 02:41:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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:

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

https://lists.mindrot.org/pipermail/openssh-unix-dev/2009-March/027491.html
https://lists.mindrot.org/pipermail/openssh-unix-dev/2008-November/026981.html
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.
http://admin.fedoraproject.org/updates/openssh-5.2p1-6.fc11
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.