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
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.
Notably, FreeBSD, which has never included it by default.
bash: warning: evil: ignoring function definition attempt
bash: error importing function definition for `evil'
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.
How about "I don't run bash"? There are other perfectly good shells, you know...
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.
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.
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.
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".
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?
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...
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.
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.
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 very common, particularly with monitoring pages, etc.
> 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
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
Then run the following command:
apt-get update && apt-get install --only-upgrade bash
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#
(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://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.
http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shoc...
It's on yum now, just yum update
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.
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.
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.