Bash 'shellshock' bug is wormable | Hacker News Reader

Bash 'shellshock' bug is wormable

blog.erratasec.com

299 pointsjgannonjr148 comments

Open articleView on HN

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

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

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.

Actually, the first test would be 'which bash', since not all systems have it installed by default.

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

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

would mean it's not?

That's the message you get on a patched machine. However, the patch is not sufficient: https://news.ycombinator.com/item?id=8365216 .

So from what I can tell, neither my Raspbian or Ubuntu setups have this second vulnerability properly patched yet (although they have the first one).

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

Or an earlier version of bash (4.1), which I'm assuming (haven't installed any patches within the last month on a centOS6 machine) hasn't got the issue?

If you see that "ignoring function definition attempt" message you definitely have the first patch applied (but not necessarily a fix for the second problem) That diagnositc was added by the patch itself. See http://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012

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

It has, there is a patch for bash 4.1

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

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.

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

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.

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

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.

You and Thomas can ignore everything I say about security. J. Random Rails Developer, on the other hand, probably gets useful signal if I start panicking. (Am I panicking? YES.)

I suspect that many folks who "don't run bash" actually do use bash quite a bit, e.g. in initscripts and various software packages.

Any decent shell script is written to use "sh" not bash, and on debian/etc sh is provided by dash not bash.

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

This more of a "should be", right? Maybe most shell scripts should use "sh" but I see "bash" way more often.

I guess it comes down to how you interpret things.

I specifically said any decent shell script. My logic is that if it is not using "sh", but instead relying on bash (or any other specific shell really), it's not a decent shell script.

If I were to amend the sentence to make the meaning clearer, I would still not use "should be", I would use "must be".

You're overreaching. I write scripts against bash, not sh, because it's a better scripting language for what I need. It's more readable and its constructs are easier (for me) to follow. I don't care about POSIX-compatibility when bash can be installed literally anywhere. It's a dependency for the devops stuff that I run and maintain, much like Ruby is a dependency and all the gems in my Gemfile.

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

I suggest you read the accepted answer at http://stackoverflow.com/questions/19428418/what-is-the-use-... for a brief look at why portable shell scripts are a better solution than bash specific scripts.

I suggest you read my post and maybe let it roll around your head that I've considered my environment and the domain of my problems in a way you aren't giving me credit for. Perhaps even, with that whole mention of devops, I do something such as--crazy thought incoming--install an updated version of bash on every system I must provision, just as I do Ruby, Python, etc.?

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

Exactly so. If I want PORTABLE, I write to "sh". If I want BASH, I write to BASH. The term "decent shell script" is wrong the way he uses it.

Perhaps he didn't deliver the point... but BASH is not a good or safe language to write to.

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.

/bin/bash is on literally every machine I ever touch. It is on every Debian machine. It is on every Ubuntu machine. It is on every OS X machine. It is on every Windows (!) machine. And there are plenty of operations that are significantly more cumbersome to write in Ruby--otherwise, sure, I would do so. Backticks are nice, but there's no `set -e` (that I am aware of) and it becomes a huge hassle to do things in a smart, error-checking way.

No-one claimed Bash isn't widely distributed and installed by default.

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.

> /bin/bash is on literally every machine I ever touch. It is on every Debian machine. It is on every Ubuntu machine. It is on every OS X machine. It is on every Windows (!) machine.

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

/bin/bash is on literally every machine I ever touch. Did you miss the operative phrase?

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

> /bin/bash is on literally every machine I ever touch. Did you miss the operative phrase?

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.

> "Decent shell script" is not a synonym for "portable shell script"

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? I already am running Chef on every machine I touch.

So you have a chef recipe to download and compile the same version of bash on every platform you use?

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?

> So you have a chef recipe to download and compile the same version of bash on every platform you use?

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.

Bash is known to have version/compatibility issues - Homebrew reports Bash 4.3, but Ubuntu only has 4.3 available for the most recent version - anything from before April will only get 4.2.

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.

That's a fair point for bash ultra-power users. It doesn't really reflect on my use case. I don't exactly pull out all the stops. I use [[ ]] and set -e, which have very familiar semantics that haven't changed for a long time, and that's about it. I am very confident in my selection of "portable bash"-isms as far back as 3.2 (running 4.x on OS X has only come on recent, I added it a couple months ago).

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.

Gosh, you are so clever.

If you can confidently assert that every shell script your system runs is "decent", then you'll have no problem. The thing is, very few of us can confidently make that assertion.

That all depends where your shell scripts come from.

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.

There is tremendous range in what a "shell script" might be. I vastly prefer bash to sh as a user shell. Often times, I have bits of logic I express in a command that I want to capture and reuse, and they get grabbed and dropped in a (frequently context specific) bin directory. I would contend that these "save me from typing it out" shell scripts should mimic what I would type myself. Once they wind up being more general, I usually rewrite them in a different language entirely. That's a very different context than something like an init script, though.

Still, isn't sh quite often implemented as an alias/symlink for bash nowdays?

Yes, but Debian and Ubuntu has changed their default shell to Dash (in 2006 I think), and embedded systems usually use some lightweight shell such as BusyBox. So far from all systems do.

Just to clarify a little:

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

Thanks for clarification!

Someone is going to be going through busybox soon, and then there (potentially) will be a whole bunch more exploitable boxes that don't have a generally have a regular update cycle.

You're right, of course. Exploitable weaknesses in busybox are going to be killer - I think shellshock will turn out to be the start of something really big.

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

As you well know, as long as your system doesn't use bash for anything, even implicitly :) Many folks are thinking that just because they switched their user's login shell to 'ksh' to be one of the cool ruby kids, that they're safe.

It won't be as simple as scanning all IP4 space because for most vulnerable hosts you still will need to know a URL of a cgi program that can cause bash to be executed (either because they're written in shell or, more likely, that there is some path found that can cause popen()/system()/etc to be called) If you read Robert Graham's blog post about his scan for this (posted to HN earlier today) he mentioned that the hosts he found by just looking at the root URL are probably a tiny subset of what's really out there.

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.

I think you underestimate attack vectors. d6c477a79ea7a633c2bb0e358e32399c1b18eb7d <-- Will ruin 1+ HNers' day sooner rather than later if they don't patch. Successful exploit doesn't require the exploit writer even knowing that vector existed to say nothing of successfully guessing a URL.

What does "d6c477a79ea7a633c2bb0e358e32399c1b18eb7d" mean?

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.

It is probably a SHA hash of a one-liner proof of concept that he has that he doesn't want to reveal as yet, but wants to prove that he was talking about at a later date.

Take for example your favorite web app server, rails, django, etc. whatever it may be. (Not saying these are necessarily exploitable, but potentially)

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

>Successful exploit doesn't require the exploit writer even knowing that vector existed to say nothing of successfully guessing a URL.

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?

What about using the exploit to remotely patch machines?

That's a very cool idea.

Ubuntu 10.04LTS - 14.04LTS appears to be patched: http://www.ubuntu.com/usn/usn-2362-1/

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

That update appears to only patch CVE-2014-6271 and not CVE-2014-7169 ( See: https://news.ycombinator.com/item?id=8365158 )

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.

Good catch, thanks!

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.

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

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

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"

Given that this is a 20 year old bug, that suggests that the number of eyes on this code were either zero or uninterested.

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

This has been there for nearly the entire history of Bash, like 2 decades.

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?

update bash (https://apple.stackexchange.com/questions/146849/how-do-i-re...) or switch to a different system default shell until bash is updated.

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.

Just apply the security updates as they arrive from Apple. The highest-risk activities like running a webserver hosting CGI scripts isn't likely to apply to you. I can't say for certain nobody will find a clever client-side attack for OS/X but right now you don't need to join in the panic that many sysadmins are (rightly) feeling today.

Are you running any remotely-accessible services? If not, I'd just wait for the next OSX update from Apple.

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?

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.

Shellshock Bug Logo - http://imgur.com/vlriele

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.

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

Wow the comments there are...

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.

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

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

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.

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.

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

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

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

iOS systems (unless jailbroken) do not have a shell of any sort; bash or otherwise.

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.

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.

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

Looking at http://code.metager.de/source/xref/isc-dhcp-debian/client/dh...

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.

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

to bash? or to /bin/sh? Or the user shell? On Ubuntu you are fine unless it explicitly calls bash or (unlikely) uses the user shell.

Ouch, what a mess. Thanks for the warning.

Is it connected to the internet? Then patch it. While you can't think of anything that could remotely execute it, you'd be damn surprised how large the attack surface is for this exploit, and how flexible it is. It's a Big Deal(TM). Everything in a Linux system uses bash (hyperbole, but not too far from the truth), and all it takes is one of those not sanitizing input and it's game over :(

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.

Yeah, the annoying thing is it sounds like there isn't a full patch yet and new vulnerabilities are being discovered. Just trying to understand if I should shut the machine down until everything is sorted out.

There's no need to shut it down. If you're concerned for some reason (if you have important data on it and/or use it on untrusted networks), just remove bash or at least make it unexecutable.

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.

The ecosystem of linux software that shells out to bash is ridiculous, and coercing an env var is a very light requirement.

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.

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

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.

Deleted comment

Huh, I literally just checked all the shells on my android device (with code that worked on my laptop earlier), and it didn't seem vulnerable. Are you talking about a different vulnerability?

My version of ash seems unaffected. Do you have more info?

    # 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

Android is not vulnerable. The person who posted a screenshot on twitter has bash installed on their phone. It is not in stock Android as far as I can tell, nor is it on my manually rooted Nexus 5. What the rooting tools install I don't know, it might include bash.

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

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.

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

I patched mine with a apt-get update sequence. It fixed the bug (first fix, not yet the second), and I didn't have to take the server down. Everything stayed up.

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.

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.

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

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?

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

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.

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.

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

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.

Thank you. This worked.

I just did this and got no upgrades.

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/ instead of http://http.debian.net/debian/

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.

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.

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

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#

CVE-2014-6271 cgi-bin reverse netcat shell

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

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

It's in the cloud images for Ubuntu 14.04.

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)

What you can do:

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.

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

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

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

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

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?

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

I think even just using DHCP put your Mac at risk: https://www.trustedsec.com/september-2014/shellshock-dhcp-rc...

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

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

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

On Debian /bin/sh is already provided by Dash

On OpenBSD, /bin/sh is a good alternative to bash.

Patched all the CentOS machines hours ago, whew.

It's on yum now, just yum update

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.

Well, that depends. Are you running Passenger?

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.

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.

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.

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.

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, you know, running Rails with Passenger.

> plain C that uses system() call?

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.

Please give me an example of how somebody not running a Web server and a collection of CGI scripts is affected. A git server? Are you running one of these? Move on, nothing to see for most of us.

You're in the wrong place. Hacker News isn't "Linux Grandmas' User Group". We're a varied bunch, many of us are admins or software developers, and yes we operate servers. For a living or otherwise. Security announcements like this are both interesting (hackers, remember?) and relevant to what many of us do.

Forgive me if I've misunderstood the problem, but isn't, for instance, a perl cgi script which happens to shell out to bash for some incidental functionality also vulnerable? The environment variable should get inherited.

Yes. Just about anything that winds up running bash with an unsanitized environment that an attacker could influence is potentially vulnerable. The GP poster has no idea what they are talking about.

Then this might be news to you:

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

Reply on news.ycombinator.com