sshd_config ForceCommand option is not enforced due to SSH_SOURCE_BASHRC option in bash

[Barry Jaspan]

The sshd_config ForceCommand directive is intended to cause that command, and only that command, to run when affected users log in. sshd invokes the command by running "<shell> -c <cmd>", where <shell> is the user's shell and <cmd> is the command specified by ForceCommand.

The most common user shell is bash. The bash manual page clearly specifies that the -c argument causes that invocation to be a "non-interactive shell", and specifies that non-interactive shells do not run ~/.bashrc.

However, Ubuntu (at least on Precise, and presumably elsewhere) compiles bash with the SSH_SOURCE_BASHRC option set. In bash's run_startup_files() function in shell.c, when SSH_SOURCE_BASHRC is defined, a top-level shell run under sshd runs ~/.bashrc, even for non-interactive shells. When the shell runs ~/.bashrc, a user that controls their own .bashrc file can execute any command they want (as themselves).

This is a security bug, largely because it is both undocumented in the Ubuntu Bash man page as the default setting, and because there is no way around it while still using bash as a user shell. An administrator who sets ForceCommand wants only that command to be able to run. By allowing bash to run ~/.bashrc, that intention is subverted. As a concrete example, consider an ISP/hosting company that runs a web application under an LXC container, and wants to allow shell commands to run inside a container---and uses ForceCommand to impose the container on commands run via ssh. If the user has a persistent home directory, either the web app or a contained shell command can edit the .bashrc, and on the next ssh login, the .bashrc file will run its commands outside of the container, subverting the limitations imposed by ForceCommand.

The bare minimum fix is for Ubuntu to change the bash man page to at least document this behavior, since it directly contradicts the current man page and can only be discovered by reading source code. A better solution would be to allow an administrator to disable the unexpected functionality, perhaps by offering a different bash package with the compile-time option turned off (and also document this in the man page).