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.
> 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.
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?
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.
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)
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 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 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.
/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).
> "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.
> 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.
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.
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.
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...
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.
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.)
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?
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.
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.
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().
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.
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.
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
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)
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?
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.
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..
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.
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