export evil='() { :;}; echo vulnerable'; bash -c echo;

Vulnerable computers will print 'vulnerable'.

Test a CGI:

curl -i -X HEAD "http://website" -A '() { :;}; echo "Warning: Server Vulnerable"'

Vulnerable scripts will emit a "Warning" header. If you get a 405 error, try it with a GET request.

I don't know the PoC fo new version which wiggles around the patch.

I've tried the PoC on ksh, csh, and dash; if they're effected, its more nuanced. Its advisable to rename bash, and replace it with a symlink to dash; it shouldn't break any scripts, and even if it does its better than getting owned.

mv /bin/bash /bin/_bash

chmod ugo-x /bin/_bash

ln -s /bin/dash /bin/bash

It most certainly will. dash provides a tiny subset of bash's functionality. Even scripts using #!/bin/sh often contain bashisms; a script using #!/bin/bash is certain to contain bashisms.

If you really want to swap out bash, swapping it out with ksh is likely to break fewer scripts (though it could still break scripts - ksh and bash are similar but not the same - so I don't recommend you do this).

And neither dash nor ksh have this "feature" of exporting functions through environment variables.

I still contend that its a good idea. Most shell scripts used by the OS are written to dash in my experience; if you break ones you've added yourself, this is perhaps a good opportunity to review their security.

Notably, FreeBSD, which has never included it by default.

    bash: warning: evil: ignoring function definition attempt
    bash: error importing function definition for `evil'

I guess I'll just have to wait until it becomes available. They're usually pretty responsive about issues like this.

Maybe you have auto-update turned on and didn't realize it?

ftp://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012

If you cannot say "I run no Linux/Unix/MacOS/compatible/etc machine which connects other machines" you should be at battle stations right now. We're all racing against a for loop and the for loop will probably have a head start.

How about "I don't run bash"? There are other perfectly good shells, you know...

Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays.

On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow.

BSDs won't have bash unless someone has gone out of their way to install it, which can be undone straightforwardly.

But it could be a long night for our Linux brethren and sistren.

Good luck, and remember to stay hydrated. :)

EDIT: obviously, don't chmod 0000 your login shell! Fix that first. Make sure whatever you switch to isn't a symbolic or hard link to bash.

In the case of OSX, /bin/sh is also bash. For some reason they are separate binaries (at least on my laptop running 10.9.5) but they're both really bash inside:

    $ ls -ld /bin/sh /bin/bash
    -r-xr-xr-x  1 root  wheel  1228240 Sep 21 21:37 /bin/bash
    -r-xr-xr-x  1 root  wheel  1228304 Sep 21 21:37 /bin/sh
    $ /bin/sh --version
    GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
    Copyright (C) 2007 Free Software Foundation, Inc.
    $ /bin/bash --version
    GNU bash, version 3.2.51(1)-release (x86_64-apple-darwin13)
    Copyright (C) 2007 Free Software Foundation, Inc.

(ETA: as I've mentioned elsewhere in this thread most people running OSX probably aren't badly impacted since they're not running CGI-based web software or other high-risk activity. I'm just pointing out that your bash-ectomy of OSX isn't as complete as you think it was)

There might be more of an impact than expected on OSX, too -- no telling what Apple does with their system services.

We've seen mention of dhcp-client and CUPS. The latter, at least, could also be an issue on OSX.

So while a lot of people are affected, your reasoning points to other issues that are very solveable

It's a considered decision, not a sign of "indecency".

"Decent shell script" is not a synonym for "portable shell script" and the presumption therein is what I was addressing.

Writing to '/bin/sh' is understandable due to its ubiquitousness.

Bash is a superset that is not so ubiquitous, so it doesn't have the advantage that writing to /bin/sh does.

If you don't want portable, then don't write to shell script. Write to Perl Ruby or Python, which is also safer and more secure.

However, unless you are patching and compiling the same version of Bash, you absolutely do not have the same version on all those machines, and that is the whole reason NOT to target Bash in shell scripts - its features are not always consistent/compatible across versions.

Yes. Yes. Yes. Yes. No (unless Cygwin is installed).

(I have init scripts for Cygwin, too, because I need Windows but life is too short for CSRSS.)

You intended that subjunctive clause to apply to all the sentences, an intent I missed. My mistake. :)

This may soon become a tempest in a teapot, as patched Bash versions are now appearing. I just patched all my machines.

Only for you. For me and a lot of others I suspect, if it isn't portable it isn't worth the trouble.

If you have to re-compile a newer/older version of a shell to get the same results across machines, any potential benefits start to seem insignificant compared to the effort involved.

How do you handle situations where bash is included by default?

Do you remove the package or just push your binary over the top?

If you don't remove it, what happens when a package update then replaces your binary?

How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?

No, I have a chef recipe to install the newest version of bash 4 everywhere. How is an implementation detail. (I use Ubuntu packages and Homebrew, I only compile on cygwin.)

> How do you handle situations where bash is included by default? Do you remove the package or just push your binary over the top?

On OS X, the only place that's the case, I replace the binary (by using the Homebrew-compiled one).

> How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?

I've written the Chef recipe to not need regular updates. I run my Chef update stuff on a weekly basis. I can do so manually if I need to.

This is my whole point - targeting /bin/sh means targeting a POSIX compliant shell, which may be implemented by any number of different codebases, with a defined standard to meet. Posix mode in Bash 4.3 should be the same as Posix mode in Bash 3.9, etc. - targeting /bin/bash means targeting whatever specific bash oddities come with the version installed.

Don't get me wrong: I could use /bin/sh. But I would have to write worse code to do it. I'll take the possibility of a bash regression over writing all my shell scripts in sh.

In my experience most of the shell scripts provided by packages for debian, do use /bin/sh.

A quick check of .sh files on a couple of squeeze/wheezy installs showed that the vast majority of shell scripts using Bash come from node modules, which quite frankly is not surprising.

By default Debian still uses Bash for interactive user shells, but since Squeeze (early 2011), /bin/sh is provided by Dash.

Dash is used because it's faster than Bash and has less dependencies so its more resilient to failures.

for more info see https://wiki.debian.org/Shell, https://wiki.debian.org/DashAsBinSh and https://packages.debian.org/wheezy/dash

But, to clarify for others, the existing shellshock PoC doesn't work on the busybox environment I tested (v1.20.2).

What we'll probably see is lots of blackhats looking at common CGI-based packages, finding a way to provoke an exploit using that, and then doing an IPv4 scan exploiting just that one. There will also be a long-tail of people mounting more directed attacks against URLs they suspect are CGI based.

Also, I'm learning about this and am primarily concerned about the possibility of remote exploits -- if a web server returns 404 for an invalid URL, how does the attack vector work if the exploit writer does not successfully guess a URL? Thanks.

Now imagine that for EVERY request, no matter if it is a valid path or not, one of the things it does is load all of the headers for the request into bash variables...

I'm not following. My CGI application is at example.com/stuff/cgi/webapp

So now the attack doesn't need to append /stuff/cgi/webapp? It can just point to example.com? How does that work?

Logging into my server, things look good -- this is why you turn on automatic security updates. :)

Although 7169 appears to be more difficult to exploit than 6271, you're not out of the woods until a patch gets distributed (+applied!) that covers both CVEs.

Seems quite likely that someone would have discovered it sooner, especially since it's so simple to exploit.

Relatedly, "many eyes makes all bugs shallow" is, and always has been, totally horsepuckey. (And despite it being horsepuckey, and horsepuckey which is trivially exploitable in that if you believe it you'll produce software which can get owned by people who are better at e.g. counting to four than you are, people still believe it to this day.)

Consider that the contraction of the more complete saying "Many eyes make bugs shallower than they would be if there were only few eyes".

Also, the BEAST bug was identified 20 years ago and nothing was done until Thai and Juliano caused a mild panic.

If you've properly deployed these tools you've greatly limit the potential impact of a DHCP based worm.

Home router? Anyone test this against Linksys junk yet?

It's sad to see an RCE somewhere so widespread and so interwoven with other software. It's also costly because now I'm questioning server integrity, thinking about what should really be re-imaged. I assume there are many more like this in the CVE pipeline...

At some point I just have to live with the fact that outside access is possible to anyone so motivated.

I think it will start to make its way out to the public with a bit more time.

Wow the comments there are...

The patch appears to have been a adequate fix to the bug that was discovered. The fact there is a second bug with a similar but not-identical attack vector, is a reflection on the robustness/correctness of the original code more than it is a reflection on the quality of the patch.

This is very similar to the pattern we saw with heartbleed: a terrible bug with a lot of publicity followed by a series of other vulnerabilities found of various severity as suddenly it was "all eyes on OpenSSL": http://www.openssl.org/news/secadv_20140806.txt

I wouldn't be surprised if we're going to see a repeat of that here.

One early analysis [0] seems to indicate that OS X not vulnerable to this sort of DHCP client exploit.

0. http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-d...

Let's say, for the sake of argument, that your ISP's DHCP server is compromised. A worm could then spread to your system from it.

This is entirely hypothetical, but not impossible.

It seems that server_name from DHCP response is passed to environment variable without sanitising.

  3437		if (check_option_values(NULL, DHO_HOST_NAME,
  3438					lease->server_name,
  3439					strlen(lease->server_name)) == 0 ) {
  3440			client_envadd (client, prefix, "server_name",
  3441				       "%s", lease->server_name);

See code here: http://lists.alioth.debian.org/pipermail/pkg-dhcp-commits/20...

Basically, it may not be as immediately exploitable for desktop systems without a web-server as other bugs have been, but I wouldn't be surprised to see something pop-up in the near future.

A fair bit of warning though that some scripts might break, but at least you know why (if the alternative is to turn off the machine until you trust bash again then you may have to wait forever).

On a standard Ubuntu or Debian most shell scripts uses dash anyway so it shouldn't be too bad.

Virtually any software that takes input from the internet can be a target, and enumerating the combination of versions and configurations is futile. We all need a working bash patch.

Not running a webserver protects against GET spray-n-pray, but you shouldn't feel safe.

    # env x='() { :;}; echo vulnerable' /bin/sh -c "echo this is a test"
    this is a test
    # env x='() { :;}; echo vulnerable' /bin/ash -c "echo this is a test"
    this is a test

You could replace bash with e.g. a perl script that strips parenthesis from your environment variables, and then invokes a differently named copy of bash. That might not break anything. Then again, it might.

Just did this, except I accidentally removed both bash and dash... it wasn't fun having to compile bash from source with zsh. For whatever reason it absolutely did not want to work.

But all back to normal now.

This is very common, particularly with monitoring pages, etc.

http://pastebin.com/raw.php?i=166f8Rjx

> The question isn't whether a CGI is written in bash, but if it calls out to bash no matter how indirectly. Lots of things use the system() libc function, so if /bin/sh is bash it's game over.

Is this true? Which systems are vulnerable to this by default?

edit: reading this looks like its exploiting CGI scripts, presumeably through the host header

    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

Then run the following command:

    apt-get update && apt-get install --only-upgrade bash

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#

https://gist.github.com/schniggie/5eeeb8ac943b5c2bb356

(or maybe the "command" builtin instead? It seems to also 'properly' show the vulnerability as well, but I'm not if that would affect the test in some cases)

http://apple.stackexchange.com/questions/146849/how-do-i-rec...

If you need a temporary fix until there is a new update - this can prove to be quite useful.

http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shoc...

It's on yum now, just yum update

http://blog.phusion.nl/2014/09/25/security-advisory-phusion-...

What about the rest of your servers? I can't claim to know that none of mine don't call system() somewhere deep in them.

And I dare say there are lots of admins who do not know exactly what their servers are going to execute because they're using software written by other people. That's why we call them admins, not software developers.

By the way, system() can be used in quite a lot of languages, not just in plain C.

And there are definitely more attack vectors than CGI. CGI is just the most obvious one.

Now, an admin _must_ know every service running on entrusted boxes facing the Internet. CGI scripts hopefully are not common these days. If you run them do stop for other reasons.

So far every "attack vector" implies having shell access to the target machine in some form. No need to panic for majority of people.

Lots of code uses system()/popen() etc. If no user-controlled input is passed in as an argument, most people would have not considered that a potential vulnerability. More software than you think is going to be affected.

https://gist.github.com/anonymous/929d622f3b36b00c0be1