BA-2001-03 Multiple Problems with the Implementation of SSH ChRootGroups/ChRootUsers


Original release date: July 22, 2001
Last revised: July 22, 2001

A complete revision history is at the end of this file.

Systems Affected

A) Systems running SSH Communications, Inc’s SSH 2 implementation, using the built-in features for user login security.

B-C) Those same systems using SSH 1 compatibility.




Systems using SSH ChRootGroups to provide a secure user environment may allow more privilege than intended. (A) SFTP allows users to transfer executable files into the chroot cage. (B) SSH 1 and SCP allow users to operate outside the cage.

I. Description

SSH version 2.1.0 introduced the ChRootGroups feature, which allows system administrators a simple and secure method to grant users limited shell access. A cage is carefully constructed by the administrator to grant only such access as is required to perform a certain action or actions.

(A) SFTP, the Secure FTP feature of SSH 2, provides a secure method of transferring files between systems without the risk of password disclosure, commonly found in vanilla FTP servers. However, SFTP does not apply a umask on transfer, so files retain their original permissions.

This would allow an attacker to transfer files marked executable to the chroot cage, which could create a much higher risk of the attacker escaping the cage and compromising the system.

(B) It is common practice to install SSH 1 prior to SSH 2, as this provides backward-compatibility to users with SSH 1 clients. However SSH 1 was not designed to support ChRootGroups.

An attacker can bypass the chrooted environment on a target system (running ssh1 compatibility) by simply using an SSH 1 client to connect. This defeats the measures put in place to limit user access to the system and creates a much higher chance of the system being compromised. It is generally accepted that once an attacker has gained local access, it is only a matter of time before the root account is compromised.

(C) SCP, the Secure CoPy server provided by SSH 1 (replaced with SFTP in SSH 2) similarly does not recognize ChRootGroups. An attacker can use any SCP client to transfer files to any directory of the target system that the user account has write access to, such as the commonly world-writeable /tmp. Combined with issue B, SCP can pose a serious threat to any vulnerable system.

II. Impact

(A) An attacker can transfer executable files to the target system, contrary to restrictions implemented by the system administrator.

(B) An attacker can bypass the chrooted environment, where they will be limited only by common user/group controls.

(C) An attacker can transfer files to any directory on the target system that they have write permission to.

On their own, these issues will not grant the attacker full control over a system, however they do place that system at a much higher risk of compromise.

III. Solution

At the time of this writing, no real solution exists for these problems. However, there are workarounds to limit the potential risks involved.

(A) Restrict SFTP access to the system. Investigate chroot features of common FTP daemons.

(B-C) Do not install SSH 2 on top of SSH 1 for backward-compatibility.

IV. Demonstration


[bswopes@shiva bswopes]$ ls -l exploit
-rwxrwxr-x    1 bswopes  bswopes         0 Jul  22 12:52 exploit
[bswopes@shiva bswopes]$ sftp test@localhost
test@localhost’s password:
sftp> put exploit
exploit                     |          0 kB |   0.0 kB/s | TOC: 00:00:01 | 100%
sftp> ls -l
-rwxrwxrwx   1 501      501             0 Jul  22 12:55 exploit*
sftp> quit


SSH 1 login as chrooted user:

sh-2.04$ pwd

BhodiSoft Contact Information



[email protected]

Getting security information

BhodiSoft publications and other security information are available from our web site

Copyright 2001 Blake R. Swopes.

Revision History

July 22, 2001: Initial Release

Share the love

Leave a Reply