Ah, all right, then.
Incorrect. All web servers accept values from the client such as the name of the client OS, and they set the text of these to variables when calling things like CGI scripts which are then executed by calling the OS shell. (or they write those values to a log which may be later processed by a script and exploited that way).
So for example, one way to exploit this fault: a malicious client connects to a web server and claims to be running an OS called something which when the server assigns it to a variable, includes the necessary syntax to define a function plus the arbitrary code the attacker wishes the target machine to execute. The server does what is always does and assigns the value to a variable and calls bash to run a CGI script. Bash examines the environment it is called with and attempts to parse variables it finds with function definitions before running the code of the cgi script. In doing the variable function parsing, bash gets itself in a mess and instead executes whatever arbitrary command the attacker wishes - and then carries on as it should and executes the CGI script. If the attacker has crafted the attack well, the system now belongs to them. The attacker has no need to log in etc., the web server would have been considered to have been correctly configured (and still is really).
This exploit is actually exposed to the world through many other hosted services, not just web servers - so e.g. machines which are set to accept incoming ssh connections will also usually take some info from the calling machine and assign it to a variable before starting bash to act as the shell for the session. etc
An analogy might be that the world has been carefully locking all it's doors for decades, and thinking it's relatively safe, but someone has just noticed that everytime someone rings your phone, the caller can say a magic word and suddenly the answer machine will leap up like a possessed robot and open the front doors to let the caller walk in. No one until now even realised the answerphone could walk! (the answer phone is bash which was thought to be just doing it's thing safely away from all the locks on the doors - it's not the best analogy as actually, in this case, everyone knew the answer machine was a fully fledged death robot, but we thought it had been carefully deactivated and was just sitting quietly answering the phone for us).
As of the time of writing (afaik) the only patch available is a partial one which only prevents the very specific syntax of the first shared example of this exploit and it was quickly realised that it is relatively trivial to slightly restructure the attack and bash is still vulnerable because the flaw is much more deep seated in the logic and functionality which has been in bash since its inception and it was going to take more careful thought to be sure how best to solve this issue properly.
The reason most Mac users are not vulnerable is that most won't be running web servers or ssh or similar service which expose the flaw to external agents - but as the article correctly states, a large number of nix based servers in the world _is_ currently vulnerable because bash is so widely used. Thankfully, many embedded systems (NAS boxes, routers etc) use shells such as Busybox which are not vulnerable.
solipsismx wrote: »
Windows users are not vulnerable for once.
jexus wrote: »
<div class="quote-container" data-huddler-embed="/t/182525/apple-says-most-customers-not-vulnerable-to-shellshock-patch-coming-for-advanced-users/40#post_2608239" data-huddler-embed-placeholder="false"><span>Quote:</span><div class="quote-block">Originally Posted by <strong>knowitall</strong> <a href="/t/182525/apple-says-most-customers-not-vulnerable-to-shellshock-patch-coming-for-advanced-users/40#post_2608239"><img src="/img/forum/go_quote.gif" class="inlineimg" alt="View Post"/></a><br/><br/><br />
Who knows what lurks in windows PowerHell.</div></div><p> </p>
As I mentioned earlier, MinGW and Cygwin on Windows come with Bash, so anyone using them on windows in vulnerable.
leichter wrote: »
Be very careful about giving answers like this. Some Linux implementations of the *client* side of DHCP are vulnerable, because they use a strategy similar to that used to implement CGI scripts: When a DHCP response arrives, the information in it is placed in pre-defined environment variables, and then shell commands are invoked to actually set the network configuration. This is the quick-and-dirty way to do things as you don't have to re-write the complicated code that manipulates the configurations - you just use the already-existing command line utilities. Unfortunately, it's vulnerable to this attack.
I've seen claims that, while very old versions of OSX used this technique, Apple long ago re-wrote the DHCP daemon to do the work directly, rather than relying on command line utilities. But Apple, or someone who's really dug into the details of the code, would have to confirm this.
Keep in mind that it's actually a standard Apple design to have a GUI application that's really a front end to a command-line program. For example, Disk Utility is (mainly) a front end to the "diskutil" command line program. Go to a terminal window and type "man diskutil" and you'll see everything you can do in Disk Utility - and more. Note also that the commands that produce output - like "list", which lists the disks known to the system - have a "-plist" option. Command line programs that are used as backends to GUI applications usually have this kind of option: It produces output in a format that the GUI application can easily understand and format in a nice way, rather than the default output that's intended for humans to read.
This is a *great* feature of OSX: Pretty much anything you can do from the GUI you can also do from the command line, hence from shell scripts. Often, the command line programs provide extra, sophisticated operations that Apple hasn't (yet?) found a nice way to present in the GUI, and that most people don't need anyway. (The classic example of this is mdfind, the command line program that implements Spotlight searching. It has a ton of complex options that can do amazingly sophisticated stuff way beyond what the Spotlight interface currently makes available.)
However, this design pattern does leave the *potential* for problems from Shellshock. It's *very hazardous* at this point to make absolute statements about what is, or is not, vulnerable. This is a *bad* bug - two bugs by now, in fact; the first patch issued by the bash maintainers was quickly followed by the discovery of another related vulnerability that wasn't blocked. Those criticizing Apple for not issuing a quick patch might consider just how many quick patches they are willing to install before things settle out.
sputuk wrote: »
An analogy might be that the world has been carefully locking all it's doors for decades, and thinking it's relatively safe, but someone has just noticed that everytime someone rings your phone, the caller can say a magic word and suddenly the answer machine will leap up like a possessed robot and open the front doors to let the caller walk in. No one until now even realised the answerphone could walk! (the answer phone is bash which was thought to be just doing it's thing safely away from all the locks on the doors
Quality, not quantity...
It's why I only post sparingly, too.
benjamin frost wrote: »
Quality, not quantity...
It's why I only post sparingly, too.
This is a fairly easy fix, and it's already available. I'm really surprised Apple hasn't taken this opportunity to distribute the fix more quickly to Macs as a sign that they are serious about security. With the recent bad press, this would've been an easy way for them to begin repairing their creditability in the eyes of those that have doubts.
EDIT: Just read @leichter's post about Apple not offering a "quick fix", and I agree with him. Since this is a not-so-serious issue for the vast majority of Mac users, Apple is wise to proceed cautiously and ensure that all bases are covered when they finally push the software update out.