Yes you are technically vulnerable. So if you feel like panicking or billing a panicked client for a few hours of panic work, go for it!
But the reality is unless you allow SSH access from remote connections or a web server that runs server side scripting, you are not at risk. You are only truly vulnerable if someone you do not know can remotely access your machine & do so in a way where a Bash command can be executed.
Meaning your desktop Mac—which really does not run server applications of any kind—is not at any serious risk. I am willing to eat some proverbial “humble pie” here, but I do not think the majority of Mac users out there will be at risk at the end of the day.
So this issue is mainly of concern to system administrators on Mac OS X & Unix/Linux servers exposed to the world, not desktop users who do not enable SSH sharing.
Perhaps there is an edge risk of a Mac malware or virus being created to exploit this risk, but I doubt it.
EDIT: And just to elaborate how this issue is—in my humble opinion—not really an issue to most average users, yes I can run the following command from bash on Mac OS X 10.9.5:
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
And I see this:
vulnerable
hello
Guess what? That is only terrifying if you don’t rationally think this out. I had to already have been logged into my Mac to even open the Terminal. And to negate what I said about SSH above, to even get to the point I can run this test even if SSH is enabled I would still have to be logged in to begin with. And then—let’s say I get access via SSH—the command does not allow me to do ANYTHING past my normal user rights such as this:
env x='() { :;}; echo vulnerable' bash -c 'cat /etc/ssh_host_rsa_key'
Meaning if you truly are vulnerable to being exploited by this hack, your core security on the system would have to be so compromised that the fact that bash has a flaw is really the very least of your issues.
This is a concern from an overall control & rights issue as it as the potential to allow unintended access since the behavior extends outside of expected norms. But in my humble opinion, it is not a risk on par with OpenSSL or the garden variety “let me leave my password on a note taped to my screen” risks.
At the end of the day I am still patching all of my Linux/Unix servers I run as standard procedure. And will happily patch the Macs I manage once a fix is out. But for practical day-to-day use I feel fine not worrying about this since I do not understand how a flaw that does not allow for elevated user privileges adds up to anything.
UPDATE: Official word from Apple posted here; emphasis mine:
“The vast majority of OS X users are not at risk to recently reported
bash vulnerabilities," an Apple spokesperson told iMore. "Bash, a UNIX
command shell and language included in OS X, has a weakness that could
allow unauthorized users to remotely gain control of vulnerable
systems. With OS X, systems are safe by default and not exposed to
remote exploits of bash unless users configure advanced UNIX services.
We are working to quickly provide a software update for our advanced
UNIX users.”
Translation: What I said above about this being a server issue & not a client issue? Exactly.
A FINAL UDPATE: For anyone struggling with compiling from source, as of September 29th, Apple has officially released patches for Mac OS X 10.9.5, 10.8.5 as well as 10.7.5:
YET ANOTHER FINAL UPDATE: And now, Apple has just released a combination security update today that includes the bash update as well!
Note: Security Update 2014-005 includes the security content of OS X
bash Update 1.0
To check the firmware of an Intel UEFI system, such as a Mactel, boot Intel LUV (Linux UEFI Validation) distro, luv-live, run Intel CHIPSEC. It'll check for most of the publicly-known firmware vulnerabilities. You should run CHIPSEC when you first get your box, save the ROM, then occasionally re-run CHIPSEC and compare the ROMs for changes. You can use UEFItool, CHIPSEC, or UEFI-Firmware-Parser, or a handful of other tools to a forensic examination of the ROM.
For some more information about the topic and the tools involved, see my slides for a presentation I gave recently.
Best Answer
First: it's not macOS itself which is vulnerable in the first place but the firmware and related hardware is affected. In a second step your system may be attacked though.
Only some of the impacted processors are installed in Macs:
I checked some random firmware files with the tool MEAnalyzer and found at least some containing Intel Management Engine code:
This is the MacBook Pro Retina Mid 2017:
An ME entry in Family denotes Management Engine code.
In an EFIFirmware2015Update.pkg 2 of 21 firmware files contain Intel Management Engine code which may be affected by CVE-2017-5705|5708|5711|5712.
In the macOS 10.13.1 update.pkg 21 of 46 firmware files contain Intel Management Engine code which may be affected by CVE-2017-5705|5708|5711|5712.
One source and a linked source therein state that "Intel ME is baked in every CPU but according to The Register (0) the AMT part is not running on Apple hardware." AMT is also related to an older vulnerability and the Register link refers to this. Then the firmware may not be affected by CVE-2017-5711|5712 because AMT isn't present on Macs.
But some of the recent vulnerabilities don't require AMT.
In my opinion it's unclear whether Macs are affected by the Intel Q3’17 ME 11.x vulnerability - probably only Apple can tell. At least Macs are not affected by the SPS 4.0 and the TXE 3.0 bugs!