There’s a pretty nasty bash bug which parses trailing strings after function definitions in the values of environment variables. Basically this bugs allows remote code execution with a well crafted http request. It affects about 25 years worth of bash versions, and there is no fix for it yet.
A quick test to see this on your system is:
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"
If your terminal echoes out busted, you’re vulnerable. Keep a lookout for patches in the next few days.
and there is no fix for it yet
Other than upgrading to a non-vulnerable version of Bash?
As far as remote vulnerabilities are concerned, that is an issue, but mostly with CGI scripts that use system() calls, which were always risky. I hope there aren’t too many of them, although I know there are some.
Edit: Looks like most *nix packages have an update for this. Do install.
There is an incomplete patch, but requires you to recompile bash. If you’re an OSX user, I would wait for the official OSX update. I also would not be surprised to see other attack vectors to appear.
On the other hand any dev-ops person right now should be
Or weeping quietly and reaching for the bottle…
I read the link, but I’m pretty ignorant.
sooo… I need to load a malicious page to be attacked or what? should I just quit my browsers until I get software updates from mac, or as long as I go to the places I usually go I’m cool?
can I disable bash? should I? will that break my ability to receive the patch from apple? will my browser not work if I do?
As a normal user, keep a look out for updates from apple, and stay off of public wifi until you’re patched.
The scary bit is that bash is used in a lot of different places, so there are potentially a lot of other vectors of attack. Expect a lot of servers, and embedded systems to be compromised.
For further technical reading, check out: http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html
Edit: It also looks like a full patch is available: http://seclists.org/oss-sec/2014/q3/734
ATTN CASUALS: the patches are arranged for each version of bash available. which one do you have? if you think you’re gonna find out by looking in your utilities folder, by typing “bash” into the search bar, or looking in any of the terminal pull-down menus, you will be disappointed.
open Terminal, then type /bin/bash --version into the terminal (more here.) then go to the above link and match your patch
@gwwar so I downloaded the appropriate patch then clicked on it. there was no “you are downloading a file from the internet do you want to proceed”, there was no unzipping; a task bar showed for a fraction of a second and that was it. I couldn’t read the text on it that fast, but I guess that means it worked?
the first link you posted says my router is vulnerable. I need to look for a router patch now, too, correct? this assumes someone made/will make one for my particular router.
My ISP is Clear, which uses Motorola wireless modems, do I care about vulnerabilities there or is that Clear’s problem?
thank you for helping us ＼（＾ ＾）／
Basically a full patch is available, so look out for OS security updates. OSX is a bit slow about this, but other *nix distros should have fixes out shortly.
lots of people want to bash bash, but bashing bash bypasses brilliant csh, see? See, some say csh shares some shellshock syntax but bash’s broken bits patch barely belay the bug
For more exotic or too old systems, or where a quick stopgap solution is needed, here is a wrapper that filters out suspect-value variables and refuses to run the shell when they are detected and writes a syslog message.
http://seclists.org/oss-sec/2014/q3/737
Deployed on a pair of machines, briefly tested, seems working.
And now all y’all have enough time to not screw up the update.
Edit: It is a very simple C file that can be compiled without dependencies
cc -o bash-shellshock bash-shellshock.c
(edit: try here if the bash-shellshock binary really works. It should but one never knows. TEST EVERY STEP, things can go wrong without expectations. The stupidest omission, the most trivial typo, YOU TOO are liable to making them.)
Then copy /bin/bash to /bin/bash.real (defined in bash-shellshock.c), run bash.real, from it
mv /bin/bash /bin/bash.old; mv bash-shellshock /bin/bash
(this way minimizes the time the system is without bash, so minimizes the downtime window to some milliseconds).
Then test if everything dependent on /bin/bash works; spot checks should suffice. Try to log in from another terminal to see if you did not lock yourself out accidentally. Then, and not earlier, exit your running shell.
This should work on pretty much anything, any version, as long as you have a functional C compiler. Will keep you watertight, even if it is a chewing-gum style of repair, for a while, until a proper repair can be done (e.g. after returning from a scheduled party).
shh, @SSH
I calmed down a bit and realized that this is actually a pretty good news. This means many of those embedded-linux devices can now be rooted, via e.g. the DHCP exploit!
Do you already have a ssh server on the box that runs as user? Run it via the exploit as root, then secure yourself the ownership rights that rightfully belong to you.
Edit: Won’t be as good. Embeded things typically don’t use full-grown bash but some castrated replacement. Oh well…
My mac patched this morning (rather dramatically from my perspective) and still echoed “busted” running the test above. My mental parser is not up and running yet this morning so I don’t know if it’s supposed to echo both busted and stuff (which it did) and what that means on the whole. Guess no programming for me today (because of the mental parser problem, not because of the mac (which is only one of several computers I own) 
).
Good thing I am very selective about what I connect my devices to in terms of networks.
Pretty new to the mac stuff. Do we have the option of replacing/updating bash? Preferably one that doesn’t require me to set up a development suite on relatively low end hardware (it’s an 11" air)?
@Ignatius I didn’t get any updates from mac. still echoing “busted stuff”
where do I put it?
/bin is usually where bash goes in *NIX and that appears to be the case here but it’s also possible that’s just the symlink that’s a pointer to somewhere else.
If I’m reading the following right, I think that is the actual location of the file.
cd /bin
ln -l bash
-r-xr-xr-x 1 root wheel 1228240 May 10 07:12 bashHowever, I’m not seeing anything on that thread that indicates what each was compiled for and since I’m not familiar with the forum (and don’t have a backup mac to screw around with), I’m a little leery to just download the file and replace my bash with it.
What I would suggest (if you trust the source) is extracting it to anywhere and launching it to see what happens. Unfortunately, being *NIX, it may be a bit more complicated than that. You may need to chmod the file (chmod u=rx filename (adds read and execute to the file’s owner, which should be you)) and if it doesn’t launch by double clicking it, you may need to launch it from your existing bash terminal by getting to the directory you placed it in and typing in ./<filename>
Rather than doing any of this, though, I would prefer both of us waited until someone who is more familiar with the guts of Mac were to chime in. 
ETA: I read a little bit more into the thread and I’m about 90% certain this was not compiled for Mac. Mac runs on a BSD base and even if the hardware is compatible, the executables are generally not something you can copy from one distro to another let alone from a likely Linux based compile to a modified BSD base.
ETA2: See shaddack’s post below. This post I wrote may have some useful hints about getting around in *NIX but replacing bash should not be done without following other steps.
First, make sure you can boot the thing from a USB or a CD/DVD. Having a bootable medium (or at least another computer to make one on) is a must. Because problems happen.
DO NOT just replace the original file. Extract the new one to your local directory and test it there (run “./bash”, explicitly saying you want to run it from the current directory, not from the $PATH one). Run it, and do some operations within it (at least “ls”). It will tell you it can run and exec other files. Not a comprehensive test but covers at least the links to libraries. Do not exit it yet, the modifying operations are better done from it as you won’t pull the carpet under your feet that way (removing a file you are running at the moment, which is the shell).
After testing, copy it to /bin/bash.new and do
mv /bin/bash /bin/bash.old; mv /bin/bash.new /bin/bash
Then check the version number (/bin/bash --version) and you should be good to go.
You can optionally remove the /bin/bash.old later once you’re confident the new one runs well. Not before; if something goes wrong, you want to still be able to boot from a USB disk (or so), mount the root disk, move the bash.old back to bash, and be back where you were at the beginning, only a bit older and a bit hair-grayer.
Edit: As said above, if it is not compatible with the OS (which it would not be if it is compiled for another one), it will not work. It however shows up at the early part of the test as the executable won’t run.
I greatly appreciate you taking the time. guess I’ll just hope I get a mac update that works in a timely fashion.
of course, we all know the real solution:
Thanks for weighing in. I’m a total noob at Mac and only so so at Linux.
Woah, folks, before you exorcise your computer by putting in the microwave, wait for the official update from your OS. Apple is just horrifically slow on critical security updates.
In the meantime, for advanced users this means not SSHing into unpatched boxes. Here’s a list of current attack vectors: https://www.dfranke.us/posts/2014-09-27-shell-shock-exploitation-vectors.html
If you really want to recompile bash, here are the instructions to do so: http://apple.stackexchange.com/questions/146849/how-do-i-recompile-bash-to-avoid-shellshock-the-remote-exploit-cve-2014-6271-an
wait… so you’re saying… DON’T put my computer in the microwave?
