
Bash 'shellshock' bug is wormable - jgannonjr
http://blog.erratasec.com/2014/09/bash-shellshock-bug-is-wormable.html
======
fabulist
Test your local machine:

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

Vulnerable computers will print 'vulnerable'.

Test a CGI:

curl -i -X HEAD "[http://website"](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

~~~
agwa
> Its advisable to rename bash, and replace it with a symlink to dash; it
> shouldn't break any scripts

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.

~~~
fabulist
You're right, and I didn't find this out until after I couldn't edit my post.
My mistake.

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.

------
patio11
Yep. We're currently _basically_ waiting to see which completes first: a) a
patch for bash which actually works gets released and then trickles into the
various ways to get it on every machine in the world or b) someone writes ~10
lines of payload code (download rootkit, execute, connect to IRC channel, join
botnet, etc) and then just hits everything in IP4 space with a for loop.
Optionally, the for loop gets distributed to new nodes joining the bot net.

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.

~~~
cperciva
_I run no Linux /Unix/MacOS/compatible/etc machine which connects other
machines_

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

~~~
quesera
Or "I don't run UNIXes that default to bash, or hide it under /bin/sh, etc."

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.

~~~
bodyfour
> On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect
> so far.

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.
    

So even if you chmod bash to 0 you could still be exposed by anything that
uses /bin/sh -- system(), popen(), most shell scripts, etc

(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)

~~~
quesera
Yikes, yes. Thanks for pointing that out!

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.

------
eah13
Honest question: does this mean this vulnerability has been in bash for
essentially its entire history and someone only discovered it now?

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

~~~
patio11
Ease of exploitation and ease of discovery have basically nothing to do with
each other.

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

~~~
gioele
> Relatedly, "many eyes makes all bugs shallow" is, and always has been,
> totally horsepuckey.

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

~~~
Tloewald
But then there's the "Many eyes lead to a sense of complacency" issue -- like
"No-one ever got fired for buying IBM|Microsoft|Blackberry"

------
dustingetz
I have a macbookpro which is my developer workstation. It is in a default
configuration, it is on 12 hours a day, always behind a NAT. What do I need to
do to protect myself?

~~~
ProCynic
update bash ([https://apple.stackexchange.com/questions/146849/how-do-i-
re...](https://apple.stackexchange.com/questions/146849/how-do-i-recompile-
bash-to-avoid-the-remote-exploit-cve-2014-6271)) or switch to a different
system default shell until bash is updated.

~~~
maldeh
Keep in mind that /bin/sh is bash on OS X. So if you have any scripts with the
#!/bin/sh preamble you'll have to replace the default sh too.

------
blocke
Rogue DHCP servers should not be a problem in any decently engineered
enterprise or college campus network. Cisco switches have included DHCP
snooping for years which when used only allows authorized switch ports to act
as a DHCP server. Any decent enterprise wireless platform should either have
transparent firewall functionality to block client DHCP responses or an
equivalent to DHCP snooping.

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?

------
zaroth
Shellshock is a perfect name coming after Heartbleed. But this bug is
suffering from lack of marketing, lagging in the news behind the iOS update
being pulled.

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.

~~~
prawn
Front page of the site of one of the major Australian newspapers: "Largest bug
ever hits the internet"

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

~~~
zaroth
I'm sure they've picked up now that the patch was bad. Should be an
interesting day.

Wow the comments there are...

~~~
timv
If your conclusion that _the patch was bad_ is based on the fact that
CVE-2014-7169 still exists, I think that's an unfair assessment.

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.

~~~
bodyfour
... and also a reflection of how much security attention this one obscure
feature has been receiving in the last 24 hours.

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](http://www.openssl.org/news/secadv_20140806.txt)

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

------
Animats
What about simply disabling CGI in Apache? If you're not using it, turn it
off. Use "\--disable-cgi" at Apache launch. This will break some "control
panels", but you probably shouldn't be using a CGI-based control panel in 2014
anyway.

------
TheSoftwareGuy
I didn't realize iOS and OS X DHCP could be vulnerable. This just went from
"Man a lot of other people should be worried about this" to "shit, shit, shit,
shit, shit", since I don't run a web server.

~~~
sjy
Have you got a source for OS X DHCP being vulnerable? OS X has a copy of bash
at /bin/sh so it's pretty vulnerable if you can find a way to remotely set
environment variables and call system().

~~~
TheSoftwareGuy
It was in the article linked. at the bottom it mentioned them

~~~
stygiansonic
Unless the article was changed, the author only questioned whether they were
vulnerable, and did not assert that they were: " _One key question is whether
Mac OS X and iPhone DHCP service is vulnerable..._ "

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...](http://complexitydaemon.wordpress.com/2014/09/26/bash-os-x-dhcp-and-
you/)

------
tdicola
As someone who just runs an Ubuntu 14.04 desktop machine without any web
server should I be concerned? I don't really see how anyone could remotely
execute bash on my system.

~~~
LeoPanthera
It's hard, but not impossible. Apparently your DHCP client passes responses
from the DHCP server to bash.

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.

~~~
pbhjpbhj
What responses does it pass, does it not sanitise them? Can anyone link to
details of what DHCP does that's relevant here? Thanks.

~~~
monort
Looking at [http://code.metager.de/source/xref/isc-dhcp-
debian/client/dh...](http://code.metager.de/source/xref/isc-dhcp-
debian/client/dhclient.c)

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);
    

And script that is run after that (dhclient-script) is written in bash at
least on Debian.

~~~
isaaccp
check-option_values() actually checks DHO_HOST_NAME to be only alphanumeric
and '.':

See code here: [http://lists.alioth.debian.org/pipermail/pkg-dhcp-
commits/20...](http://lists.alioth.debian.org/pipermail/pkg-dhcp-
commits/2011-April/000121.html)

------
grimtrigger
Could anyone provide a simplified explanation for what this is and what it
means?

~~~
amalcon
This is a completely bonkers, Slammer-level hair-on-fire vulnerability.
Remember Heartbleed? This is much worse. If you have a computer with an OS
other than Windows or Android, your safest bet is to unplug it from the
Internet until the bash developers figure this all out.

~~~
grimtrigger
And my servers? Is there anything I can do without taking them offline?

~~~
amalcon
Well, you could remove bash entirely (say, by replacing it with a link to
dash). Doing this will likely break things, however, up to and including
rendering the machine unbootable depending on which distribution it is and how
the init scripts are written.

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.

~~~
barsonme
> Well, you could remove bash entirely (say, by replacing it with a link to
> dash)

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.

------
hamstergene
I'm really surprised how many people out there write CGI in Bash. That's one
of the things which would have never crossed my mind.

~~~
sophacles
It's less about writing CGI in bash, and more about writing CGI, then
eventually calling system() from within the CGI program.

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

------
aus_
Shellshock is also "reverse-shell-able". This Python script relies on /dev/tcp
which is not available by default on some distros. (Source: @ortegaalfredo)
But you could probably rework it to use netcat.

[http://pastebin.com/raw.php?i=166f8Rjx](http://pastebin.com/raw.php?i=166f8Rjx)

------
btown
From one of the comments:

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

~~~
hackcasual
I think you need that + the ability to add anything to an environment
variable. Not sure how easy that is.

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

~~~
fabulist
Setting an environment variable is often pretty easy, but the Host: header is
the wrong way to go. The webserver will usually ignore a bad Host: header.
User-agent: is much more availing.

~~~
bodyfour
CGI will typically pass most any header along as a HTTP_headername environment
variable (HTTP_HOST is just one example) I'd expect most malicious exploiters
to use a non-standard header, since User-Agent's value is often logged.

------
deanclatworthy
Can anyone outline some clear steps for those of us on Debian Squeeze who have
not yet got a patch?

~~~
thaumaturgy
Yes, you can switch to squeeze-lts and then update just bash. First, add the
following two lines to your /etc/apt/sources.list:

    
    
        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
    

(you do not need to change or remove any other lines from sources.list).

Then run the following command:

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

...which will update your apt sources (but _not_ your installed software) and
then will upgrade bash and only bash.

~~~
lemming
I just did this and got no upgrades.

~~~
thaumaturgy
squeeze-lts is only available for i386 or amd64 architectures, I think, or you
might be hitting an out-of-date mirror. You might try
[http://mirror.cc.columbia.edu/debian/](http://mirror.cc.columbia.edu/debian/)
instead of [http://http.debian.net/debian/](http://http.debian.net/debian/)

~~~
lemming
Using Columbia didn't help either. Using uname -m shows x86_64 so I guess
that's it. I'll just have to wait for another update.

~~~
thaumaturgy
Silly question, but did you use sudo for the apt-get? I forget to do that
sometimes. Because I'm a bit stumped why you're not getting the update, you
should be.

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

------
schniggie
CVE-2014-6271 cgi-bin reverse netcat shell

[https://gist.github.com/schniggie/5eeeb8ac943b5c2bb356](https://gist.github.com/schniggie/5eeeb8ac943b5c2bb356)

~~~
verroq
Approximate 0% of production systems have netcat. Just pick your favourite one
liner from [http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-
ch...](http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet).

~~~
wiredfool
It's in the cloud images for Ubuntu 14.04.

------
pdkl95
This is _probably_ just a local problem in what I will euphemistically
describe as my "very highly customized" shell, but... it might be useful to
use "/usr/bin/env instad of just plain "env" in that one-liner test for the
vulnerability.

(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)

------
urs2102
What you can do:

[http://apple.stackexchange.com/questions/146849/how-do-i-
rec...](http://apple.stackexchange.com/questions/146849/how-do-i-recompile-
bash-to-avoid-the-remote-exploit-cve-2014-6271-and-cve-2014-7)

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

------
daviddede
It absolutely is. Specially now with thousands of cPanel servers known to be
vulnerable:

[http://blog.sucuri.net/2014/09/bash-vulnerability-shell-
shoc...](http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shock-
thousands-of-cpanel-sites-are-high-risk.html)

------
milankragujevic
Smart little tool to check if your website is vulnerable
[http://milankragujevic.com/projects/shellshock/](http://milankragujevic.com/projects/shellshock/)
It can also do a deep check that checks many known URLs, not only the home
page.

~~~
paulpepper
Is it possible for you to make the source for your test publicly available?

------
ccvannorman
Sorry in advance for noobing up this thread, but can you clarify this? As a
Mac OS X user who connects to public wifi often, I'm still in the dark about
whether I should literally turn off my wifi for now.. or am I safe?

~~~
wglb
The problem comes about if your mac is serving web pages. If you aren't then
there is less worry.

~~~
Salemzzz
I think even just using DHCP put your Mac at risk:
[https://www.trustedsec.com/september-2014/shellshock-dhcp-
rc...](https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-
concept/)

~~~
wglb
That is true, if you don't control where the Mac can contact a DHCP server.

------
walterbell
What are the best OS-specific alternatives to bash, which could be linked to
/bin/sh until bash fixes are stable?

~~~
cperciva
On FreeBSD, /bin/sh is a good alternative to bash.

------
ck2
Patched all the CentOS machines hours ago, whew.

It's on yum now, just yum update

------
krunkosaurus
Isn't this all just armchair prophesying? Let's see some screenshots actual
exploits from anyone. It's hard to gain access to someone's shell unless it's
1990 and a server is using CGI-BIN. People are retweeting that this is "WORSE
THAN HEARTBLEED!!!!111!" but Heartbleed literally left practically every
server susceptible. I ran sample exploit code against a number of tests hosts
and saw mysql queries and passwords streaming in plain text. Yeah shellshock
is a big deal but I've yet to the ground rumble and shake and Y2K x 10000
happen. This seems like a big deal but it actually isn't. Most likely no one
can access your shell. Patch and move on.

~~~
eropple
Well, that depends. Are you running Passenger?

[http://blog.phusion.nl/2014/09/25/security-advisory-
phusion-...](http://blog.phusion.nl/2014/09/25/security-advisory-phusion-
passenger-cve-2014-6271-bash-vulnerability/)

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.

------
f00ber
Oh stop this stupidity already. If you are not running a Web server that
spawns bash when serving an HTTP request, then you are NOT vulnerable.

Are you running a Web server that uses CGI scripts written in shell or plain C
that uses system() call? If you do, you have had other problems long before.

There are some grumblings about DHCP _client_ setups on Linux passing
parameters via environment variables to shell scripts executed by bash, but I
am yet to see this. This would be a problem, but probably easily fixable.

No need to panic or even patch anything (as always). If you running servers on
your machine and allow inbound connections you should know exactly what those
servers are and what they execute on behalf of external users.

This is NOT remotely exploitable.

It's an ad campaign for "security researchers" people.

~~~
clarry
It is hilarious that you claim this is not remotely exploitable _in response
to a post describing how a very simple and limited scan has already found
thousands of vulnerable hosts in a short timeframe_.

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.

~~~
f00ber
Well, let these _admins_ worry about this. This is of no concern for the
moment for a regular Linux or OS X user.

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.

~~~
ccvannorman
Can you clarify this? As a Mac OS X user who connects to public wifi often,
I'm still in the dark about whether I should literally turn off my wifi for
now..

