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.
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".
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.
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.
> /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).
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.
> "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.
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.
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.
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)
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.
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.
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...
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.
> 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.
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.
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.
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
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?
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.
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.
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.
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.
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?
> 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.
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)
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.
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?
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.
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.
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.
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..
I don't think DHCP in Mac OS X is affected. I am yet to see a proof that any Linux client is affected either. I am pretty sure that a few dozen servers that happily serve Web content within my reach are not affected either.
If idiots could stop spreading panic and clearly state the conditions and risks, we'd all be served better.
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.
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.
Well, then do be clear that "If you are a Linux admin that runs a Web server that invokes code via old style CGI interface, then go and update". Please stop spreading panic among uninformed people.
If you are running stuff via CGI or allow random people to invoke shell on your servers, then you have bigger problems than a bug in bash. A shell was never meant to be secure.
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.
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.
As i understand, this is ussless, cuz nobody stores any scripts in /cgi-bin folders, or maybe i just didint understand it right, can someone explain how would you exploit it ?
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:
156 comments
[ 2.7 ms ] story [ 198 ms ] threadIf you cannot say "I run no Linux/Unix/MacOS/compatible/etc machine which connects other machines" you should be at battle stations right now. We're all racing against a for loop and the for loop will probably have a head start.
How about "I don't run bash"? There are other perfectly good shells, you know...
So while a lot of people are affected, your reasoning points to other issues that are very solveable
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".
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.
It's a considered decision, not a sign of "indecency".
"Decent shell script" is not a synonym for "portable shell script" and the presumption therein is what I was addressing.
Writing to '/bin/sh' is understandable due to its ubiquitousness.
Bash is a superset that is not so ubiquitous, so it doesn't have the advantage that writing to /bin/sh does.
If you don't want portable, then don't write to shell script. Write to Perl Ruby or Python, which is also safer and more secure.
Yes. Yes. Yes. Yes. No (unless Cygwin is installed).
(I have init scripts for Cygwin, too, because I need Windows but life is too short for CSRSS.)
You intended that subjunctive clause to apply to all the sentences, an intent I missed. My mistake. :)
This may soon become a tempest in a teapot, as patched Bash versions are now appearing. I just patched all my machines.
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.
Only for you. For me and a lot of others I suspect, if it isn't portable it isn't worth the trouble.
If you have to re-compile a newer/older version of a shell to get the same results across machines, any potential benefits start to seem insignificant compared to the effort involved.
How do you handle situations where bash is included by default?
Do you remove the package or just push your binary over the top?
If you don't remove it, what happens when a package update then replaces your binary?
How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?
No, I have a chef recipe to install the newest version of bash 4 everywhere. How is an implementation detail. (I use Ubuntu packages and Homebrew, I only compile on cygwin.)
> How do you handle situations where bash is included by default? Do you remove the package or just push your binary over the top?
On OS X, the only place that's the case, I replace the binary (by using the Homebrew-compiled one).
> How often do you update the recipe to make sure it's getting the latest stable version and applying security patches?
I've written the Chef recipe to not need regular updates. I run my Chef update stuff on a weekly basis. I can do so manually if I need to.
This is my whole point - targeting /bin/sh means targeting a POSIX compliant shell, which may be implemented by any number of different codebases, with a defined standard to meet. Posix mode in Bash 4.3 should be the same as Posix mode in Bash 3.9, etc. - targeting /bin/bash means targeting whatever specific bash oddities come with the version installed.
Don't get me wrong: I could use /bin/sh. But I would have to write worse code to do it. I'll take the possibility of a bash regression over writing all my shell scripts in sh.
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
Unfortunately, bash shows up in surprising places, including default Solaris installs nowadays.
On OSX and Solaris, I've chmod'ed 0000 /bin/bash with no apparent ill effect so far. I'll put more effort into establishing its acceptability as a solution tomorrow.
BSDs won't have bash unless someone has gone out of their way to install it, which can be undone straightforwardly.
But it could be a long night for our Linux brethren and sistren.
Good luck, and remember to stay hydrated. :)
EDIT: obviously, don't chmod 0000 your login shell! Fix that first. Make sure whatever you switch to isn't a symbolic or hard link to bash.
In the case of OSX, /bin/sh is also bash. For some reason they are separate binaries (at least on my laptop running 10.9.5) but they're both really bash inside:
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)
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.
But, to clarify for others, the existing shellshock PoC doesn't work on the busybox environment I tested (v1.20.2).
Logging into my server, things look good -- this is why you turn on automatic security updates. :)
Although 7169 appears to be more difficult to exploit than 6271, you're not out of the woods until a patch gets distributed (+applied!) that covers both CVEs.
What we'll probably see is lots of blackhats looking at common CGI-based packages, finding a way to provoke an exploit using that, and then doing an IPv4 scan exploiting just that one. There will also be a long-tail of people mounting more directed attacks against URLs they suspect are CGI based.
Also, I'm learning about this and am primarily concerned about the possibility of remote exploits -- if a web server returns 404 for an invalid URL, how does the attack vector work if the exploit writer does not successfully guess a URL? Thanks.
Now imagine that for EVERY request, no matter if it is a valid path or not, one of the things it does is load all of the headers for the request into bash variables...
I'm not following. My CGI application is at example.com/stuff/cgi/webapp
So now the attack doesn't need to append /stuff/cgi/webapp? It can just point to example.com? How does that work?
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...
> The question isn't whether a CGI is written in bash, but if it calls out to bash no matter how indirectly. Lots of things use the system() libc function, so if /bin/sh is bash it's game over.
Is this true? Which systems are vulnerable to this by default?
edit: reading this looks like its exploiting CGI scripts, presumeably through the host header
You could replace bash with e.g. a perl script that strips parenthesis from your environment variables, and then invokes a differently named copy of bash. That might not break anything. Then again, it might.
Just did this, except I accidentally removed both bash and dash... it wasn't fun having to compile bash from source with zsh. For whatever reason it absolutely did not want to work.
But all back to normal now.
Let's say, for the sake of argument, that your ISP's DHCP server is compromised. A worm could then spread to your system from it.
This is entirely hypothetical, but not impossible.
It seems that server_name from DHCP response is passed to environment variable without sanitising.
And script that is run after that (dhclient-script) is written in bash at least on Debian.See code here: http://lists.alioth.debian.org/pipermail/pkg-dhcp-commits/20...
Basically, it may not be as immediately exploitable for desktop systems without a web-server as other bugs have been, but I wouldn't be surprised to see something pop-up in the near future.
A fair bit of warning though that some scripts might break, but at least you know why (if the alternative is to turn off the machine until you trust bash again then you may have to wait forever).
On a standard Ubuntu or Debian most shell scripts uses dash anyway so it shouldn't be too bad.
Virtually any software that takes input from the internet can be a target, and enumerating the combination of versions and configurations is futile. We all need a working bash patch.
Not running a webserver protects against GET spray-n-pray, but you shouldn't feel safe.
Seems quite likely that someone would have discovered it sooner, especially since it's so simple to exploit.
Relatedly, "many eyes makes all bugs shallow" is, and always has been, totally horsepuckey. (And despite it being horsepuckey, and horsepuckey which is trivially exploitable in that if you believe it you'll produce software which can get owned by people who are better at e.g. counting to four than you are, people still believe it to this day.)
Consider that the contraction of the more complete saying "Many eyes make bugs shallower than they would be if there were only few eyes".
Also, the BEAST bug was identified 20 years ago and nothing was done until Thai and Juliano caused a mild panic.
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
Notably, FreeBSD, which has never included it by default.
Maybe you have auto-update turned on and didn't realize it?
ftp://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012
I guess I'll just have to wait until it becomes available. They're usually pretty responsive about issues like this.
It most certainly will. dash provides a tiny subset of bash's functionality. Even scripts using #!/bin/sh often contain bashisms; a script using #!/bin/bash is certain to contain bashisms.
If you really want to swap out bash, swapping it out with ksh is likely to break fewer scripts (though it could still break scripts - ksh and bash are similar but not the same - so I don't recommend you do this).
And neither dash nor ksh have this "feature" of exporting functions through environment variables.
I still contend that its a good idea. Most shell scripts used by the OS are written to dash in my experience; if you break ones you've added yourself, this is perhaps a good opportunity to review their security.
(or maybe the "command" builtin instead? It seems to also 'properly' show the vulnerability as well, but I'm not if that would affect the test in some cases)
http://pastebin.com/raw.php?i=166f8Rjx
It's on yum now, just yum update
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?
Then run the following command:
...which will update your apt sources (but not your installed software) and then will upgrade bash and only bash.It's sad to see an RCE somewhere so widespread and so interwoven with other software. It's also costly because now I'm questioning server integrity, thinking about what should really be re-imaged. I assume there are many more like this in the CVE pipeline...
At some point I just have to live with the fact that outside access is possible to anyone so motivated.
I think it will start to make its way out to the public with a bit more time.
Wow the comments there are...
The patch appears to have been a adequate fix to the bug that was discovered. The fact there is a second bug with a similar but not-identical attack vector, is a reflection on the robustness/correctness of the original code more than it is a reflection on the quality of the patch.
This is very similar to the pattern we saw with heartbleed: a terrible bug with a lot of publicity followed by a series of other vulnerabilities found of various severity as suddenly it was "all eyes on OpenSSL": http://www.openssl.org/news/secadv_20140806.txt
I wouldn't be surprised if we're going to see a repeat of that here.
https://gist.github.com/schniggie/5eeeb8ac943b5c2bb356
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.
And I dare say there are lots of admins who do not know exactly what their servers are going to execute because they're using software written by other people. That's why we call them admins, not software developers.
By the way, system() can be used in quite a lot of languages, not just in plain C.
And there are definitely more attack vectors than CGI. CGI is just the most obvious one.
Now, an admin _must_ know every service running on entrusted boxes facing the Internet. CGI scripts hopefully are not common these days. If you run them do stop for other reasons.
So far every "attack vector" implies having shell access to the target machine in some form. No need to panic for majority of people.
If idiots could stop spreading panic and clearly state the conditions and risks, we'd all be served better.
https://gist.github.com/anonymous/929d622f3b36b00c0be1
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.
If you are running stuff via CGI or allow random people to invoke shell on your servers, then you have bigger problems than a bug in bash. A shell was never meant to be secure.
Yes, I am a systems engineer too.
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.
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.
https://github.com/ido/macosx-bash-92-shellshock-patched
http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shoc...
This is very common, particularly with monitoring pages, etc.