touch-packages team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

** Bug watch added: Debian Bug tracker #702559
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702559

** Also affects: bash (Debian) via
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702559
   Importance: Unknown
       Status: Unknown

** Information type changed from Private Security to Public

** Changed in: bash (Ubuntu)
       Status: New => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/1225096

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

Status in “bash” package in Ubuntu:
  Confirmed
Status in “bash” package in Debian:
  Unknown

Bug description:
  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).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1225096/+subscriptions