env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
If it prints “vulnerable” then yeah your bash is in trouble.
Wondering if it would be a good idea to patch the system bash on my mac (I use the homebrew bash as a login shell), and if so what’s the best way to do it.
Homebrew has the patches already, but Apple hasn’t released any patches for /bin/bash and /bin/sh. OS X10.9.5 / Security Update 2014-004 certainly doesn’t include patches for CVE-2014-6271.
Chet Ramey notified Apple days before the public release, so I suspect that either Apple’s internal severity assessment isn’t as high as RedHat’s or that their release process is so cumbersome that they need much more lead time.
This is an RCE over an unauthenticated GET given the right circumstances, so if you have a computer connected to the internet, stop reading this and upgrade. Patches are already out for Ubuntu and Arch, unsure about other distros.
As @pushcx mentions below, botnets will probably be on top of this pretty quick.
One of the attack scenarios is /sbin/dhclient getting bogus values from a dhcp server, and putting those into environment variables before running /sbin/dhclient-script which is indeed a bash script.
I’m happy to say that ISC DHCPclient seems to validate its inputs nicely and reject values like this with a cheery “dhclient: suspect value in server_name option - discarded” … found it in the source and tested with V3.1.3 (Ubuntu 10.10) and 4.2.4 (Ubuntu 14.04) and they’re okay.
Other DHCP clients should be checked, and someone, somewhere should really look at CUPS.
Note that this can CGI exploit scripts, so botndets will be scanning the web shortly.
http://seclists.org/oss-sec/2014/q3/650 has more
how to test if your bash is vulnerable: run
If it prints “vulnerable” then yeah your bash is in trouble.
Wondering if it would be a good idea to patch the system bash on my mac (I use the homebrew bash as a login shell), and if so what’s the best way to do it.
Homebrew has the patches already, but Apple hasn’t released any patches for /bin/bash and /bin/sh. OS X10.9.5 / Security Update 2014-004 certainly doesn’t include patches for CVE-2014-6271.
Chet Ramey notified Apple days before the public release, so I suspect that either Apple’s internal severity assessment isn’t as high as RedHat’s or that their release process is so cumbersome that they need much more lead time.
For what it’s worth, this patch reportedly applies cleanly to the latest OS X bash source if you want to try patching /bin/bash yourself.
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"It would be prudent to patch your login shell.
This is an RCE over an unauthenticated GET given the right circumstances, so if you have a computer connected to the internet, stop reading this and upgrade. Patches are already out for Ubuntu and Arch, unsure about other distros.
As @pushcx mentions below, botnets will probably be on top of this pretty quick.
This is not over yet… https://bugzilla.redhat.com/show_bug.cgi?id=1141597#c24
CVE-2014-7169 has been assigned to track reports of an incomplete patch.
Ubuntu has released USN-2232-1 for CVE-2014-7169.
This consists of Chet Ramey’s two line patch to the grammar, e.g. bash_4.2-2ubuntu2.2 -> bash_4.2-2ubuntu2.3
RedHat and CentOS patches for CVE-2014-7169 should now be available as well:
https://rhn.redhat.com/errata/RHSA-2014-1306.html
One of the attack scenarios is /sbin/dhclient getting bogus values from a dhcp server, and putting those into environment variables before running /sbin/dhclient-script which is indeed a bash script.
I’m happy to say that ISC DHCPclient seems to validate its inputs nicely and reject values like this with a cheery “dhclient: suspect value in server_name option - discarded” … found it in the source and tested with V3.1.3 (Ubuntu 10.10) and 4.2.4 (Ubuntu 14.04) and they’re okay.
Other DHCP clients should be checked, and someone, somewhere should really look at CUPS.
fwiw, zsh doesn’t appear to have exactly the same problem:
so if you’re using that, you could just disable bash for a while.
I’m not a zsh user, does it use the same function syntax as bash? I know ksh does not.
Yeah; that’s why i said “exactly the same”; I didn’t bother trying to actually figure out if it was still possible if you tried a little bit.
Error 503…