You can quote me “no they aren"t" even if the bug is there. This is a limited scope bug, even for advanced users. Il you are not one of those advanced thinkerers, you have nothing to worry about. Doesn't mean Apple shouldn't patch this as soon as possible of course. Though Bash is an easy compile, so most of those advance users can do it themselves quickly.
Also it should be noted in the spirit of fairness, an Apple patch may be delayed due to Apple's Bash version which I think is 3.2.51 vs the current Bash version 4.3.
Someone can correct me if I'm wrong on the above.
IIRC correctly, Apple uses older Bash due to licensing issues(GPLv2 vs GPLv3). Same issues led to the investment and tenure of llvm/clang vs GCC and the removal of Samba from OSX server 3 years ago.
Badly explained article: for someone to exploit bash, they would have to be able to log in first.
If a web server allows accessing bash, then the web server must also have an exploit.
So unless one has a guest account with shell login or is worried about illegitimate privilege escalation by legitimate users (e.g. students in a computer lab), or is stupid enough to run random shell scripts, then I don't see how this is a problem, certainly not in the way it's phrased, unless there are additional exploits/vulnerabilities besides what's in bash.
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.
You don't need to log in to exploit the flaw in Bash, but you do have to run an externally visible server (for example the web server) which provides interactive content and imports request data into environment variables. When the web server spawns the content generating scripts it does so in the default shell which in OS X is Bash.
Mac OS X DHCP doesn't run scripts.
Mac OS X is built upon a hybrid unix with a Mach micro-kernel and FreeBSD for the remainder of the kernel and user land. Consequently, most things that run to provide the UI and underlying services are launched in a shell. Most users aren't vulnerable because in order to gain access an intruder would need to be able to get a sub-process spawned with externally injected code in an environment variable.
If you do run a web server with CGI scripts you should temporarily replace the built-in /bin/sh with /bin/ksh or /bin/zsh, or if you have MacPorts installed, "dash" is a compact drop-in replacement. Do this carefully, though, or you could render the system permanently inoperable.
To fix the bug - for the paranoïd under us, because services like ssh login are default off - I found this site very helpful: http://alblue.bandlem.com
<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.
I had seen that, and your right. But that's a separate issue.
@_rick_v_" 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.
@_rick_v_"
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.
-- Jerry
Nice explanation. You should post more often than once every three years...
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
I think it's the kind of vulnerability that comes close to what's being shown in the game Watch Dogs:
[VIDEO]
Everything in the city runs on a central operating system ctOS so being able to exploit vulnerabilities offers a lot of options - unlocking cars, hacking phones, ATMs, doors, surveillance cameras, construction equipment, alarms, servers, laptops, power grids and so on using just a smartphone. The entire world runs on essentially Windows and Unix variants.
The more that devices are connected to networks or have remote control, the more dangerous even minor vulnerabilities become. This could very well have been a doomsday scenario. There are stats that suggest over 60% of servers run on some form of unix so imagine you find a vulnerable server, exploit it and then get that server to exploit other servers. It would take seconds to compromise a server. This would happen exponentially. If they erased the server contents, that could have taken more than half the world's websites offline within a matter of days, hours, maybe less.
I don't see that there's a good way to prevent it though. Operating system variety creates a lot of incompatibilities. As long as good security practises are followed and there are fast response times for fixes, it should help lower the damage. Thousands of servers have apparently been compromised already:
Governments are having to respond to it quickly. They wouldn't want their citizens stealing data or installing spyware on their machines without their consent. It says there were reports that as many as 500m devices could have been vulnerable but it's not that high due to the requirements needed to actually run the exploit.
@_rick_v_"
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.
-- Jerry
I think actually it's the other way around, most gui apps have a commandline equivalent (interface) but the apps stand on itself instead of a set of command invocations.
Important system services like launchd are introduced to replace traditional Unix services and the kernel isn't Unix at all its Mach so system services do not have to rely on Unix.
Anyway, this can be checked by looking at the processes running while a service is started or by making a trace of it.
An important point is that Apple said that a default configured system isn't at risk, and that's pretty clear (or do you think they don't know what they are talking about).
If you run sever apps on your Mac you can resolve this quickly by applying the link I posted in a previous post.
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.
-- Jerry
Nice explanation. You should post more often than once every three years...
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.
Comments
Ah, all right, then.
Someone can correct me if I'm wrong on the above.
IIRC correctly, Apple uses older Bash due to licensing issues(GPLv2 vs GPLv3). Same issues led to the investment and tenure of llvm/clang vs GCC and the removal of Samba from OSX server 3 years ago.
Badly explained article: for someone to exploit bash, they would have to be able to log in first.
If a web server allows accessing bash, then the web server must also have an exploit.
So unless one has a guest account with shell login or is worried about illegitimate privilege escalation by legitimate users (e.g. students in a computer lab), or is stupid enough to run random shell scripts, then I don't see how this is a problem, certainly not in the way it's phrased, unless there are additional exploits/vulnerabilities besides what's in bash.
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.
Mac OS X DHCP doesn't run scripts.
Mac OS X is built upon a hybrid unix with a Mach micro-kernel and FreeBSD for the remainder of the kernel and user land. Consequently, most things that run to provide the UI and underlying services are launched in a shell. Most users aren't vulnerable because in order to gain access an intruder would need to be able to get a sub-process spawned with externally injected code in an environment variable.
If you do run a web server with CGI scripts you should temporarily replace the built-in /bin/sh with /bin/ksh or /bin/zsh, or if you have MacPorts installed, "dash" is a compact drop-in replacement. Do this carefully, though, or you could render the system permanently inoperable.
Who knows what lurks in windows PowerHell.
Who knows what lurks in windows PowerHell.
As I mentioned earlier, MinGW and Cygwin on Windows come with Bash, so anyone using them on windows in vulnerable.I had seen that, and your right. But that's a separate issue.
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.
-- Jerry
Nice explanation. You should post more often than once every three years...
LOL
I think it's the kind of vulnerability that comes close to what's being shown in the game Watch Dogs:
[VIDEO]
Everything in the city runs on a central operating system ctOS so being able to exploit vulnerabilities offers a lot of options - unlocking cars, hacking phones, ATMs, doors, surveillance cameras, construction equipment, alarms, servers, laptops, power grids and so on using just a smartphone. The entire world runs on essentially Windows and Unix variants.
The more that devices are connected to networks or have remote control, the more dangerous even minor vulnerabilities become. This could very well have been a doomsday scenario. There are stats that suggest over 60% of servers run on some form of unix so imagine you find a vulnerable server, exploit it and then get that server to exploit other servers. It would take seconds to compromise a server. This would happen exponentially. If they erased the server contents, that could have taken more than half the world's websites offline within a matter of days, hours, maybe less.
I don't see that there's a good way to prevent it though. Operating system variety creates a lot of incompatibilities. As long as good security practises are followed and there are fast response times for fixes, it should help lower the damage. Thousands of servers have apparently been compromised already:
http://www.bbc.com/news/technology-29375636
Governments are having to respond to it quickly. They wouldn't want their citizens stealing data or installing spyware on their machines without their consent. It says there were reports that as many as 500m devices could have been vulnerable but it's not that high due to the requirements needed to actually run the exploit.
I think actually it's the other way around, most gui apps have a commandline equivalent (interface) but the apps stand on itself instead of a set of command invocations.
Important system services like launchd are introduced to replace traditional Unix services and the kernel isn't Unix at all its Mach so system services do not have to rely on Unix.
Anyway, this can be checked by looking at the processes running while a service is started or by making a trace of it.
An important point is that Apple said that a default configured system isn't at risk, and that's pretty clear (or do you think they don't know what they are talking about).
If you run sever apps on your Mac you can resolve this quickly by applying the link I posted in a previous post.
@_rick_v_"
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.
-- Jerry
Nice explanation. You should post more often than once every three years...
Quality, not quantity...
It's why I only post sparingly, too.
Obviously.
Last day's stats...
#1.SpamSandwich (36 posts)
#2.pazuzu (35 posts)
#3.Benjamin Frost (35 posts)
#4.Apple ][ (21 posts)
#5.Rogifan (20 posts)
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.