On a UNIX system there are two main ways of passing arguments from a parent to a child process when spawning a new process:
- the command line: a string that is usually given explicitly by the user
- the environment: a set of key/value pairs that is inherited from the parent process implicitly but that can also be modified explicitly when starting a process
(You can observe the values of the command line and the environment by looking at /proc/<pid>/cmdline and /proc/<pid>/environ.)
Only in short: when bash is started it parses the environment and applies some special processing if the value of an environment variable matches some syntax. Due to a bug (or was that intended?) it extracts part of such an environment value and executes it.
Two things are needed. You need to get a service (i.e. a remotely accessible endpoint) to
- put a value you control into any (?) environment variable
- run bash with that environment
The defining property of the environment to be inherited from the parent process amplifies the problem: once the remote attacker controls an environment variable it only needs to trigger one execution of bash somewhere in the processing of that request. I.e. even if the original process handling a request is not bash directly but will call bash anywhere during processing the issue will be triggered.
CGI is a protocol spoken between a generic HTTP server implementation (like Apache with mod_cgi) and an actual service that processes a request. The basic idea is that the HTTP server when it gets a request will run a service script that is mapped to the target URL and uses the output of that script as the HTTP response. HTTP request data (like the URL query, the path suffix, and usually many of the header values) is passed to the service as environment variables.
If now the script invokes bash during its execution... This is quite likely because many scripted languages run commands by invoking the shell (e.g. Perl's system call).
When you connect to an SSH server the SSH server will usually start a shell on that machine and relay its input and output over the network. Alternatively, the client can suggest a command to run instead of shell.
For security reasons, the server wants to override the command it gets from the client and to restrict the client's access to the machine. One such mechanism is to add a command=... term to a key line in the ~/.ssh/authorized_keys file for a user. When the client then connects to the machine using such a key, not the command sent by the client is executed but the one specified in
the .ssh/authorized_keys file.
The security issue is, that the original command the client sent is passed to the configured command as the value of the
SSH_ORIGINAL_COMMAND environment variable. If the configured command uses or invokes bash, the issue will manifest itself.
From security.stackexchange.com:
The dhclient-script network-configuration shell script is run during the DHCP process, and a number of parameters from the server (such as domain-name) are passed to it in environment variables. The script is set to be interpreted by /bin/sh, so if your system has that symlinked to /bin/bash (which is quite common), you're vulnerable.
- oss-sec thread with the original announcement where additional implications are discussed
- http://lcamtuf.blogspot.de/2014/09/quick-notes-about-bash-bug-its-impact.html