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.
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.
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?
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).
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)?
/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.
ln -l bash
However, 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.