You might also look into changing the default shell (but beware, scripts with bashisms in them...).
4.3-7ubuntu1.1
Yes. Patch is out.
replace bash 4.1-2ubuntu3
I guess apt-get from one of Linode's mirrors saves bandwidth? Or is it just more polite?
Ubuntu 14.04 LTS: bash 4.3-7ubuntu1.1
Ubuntu 12.04 LTS: bash 4.2-2ubuntu2.2
Ubuntu 10.04 LTS: bash 4.1-2ubuntu3.1
For releases in-between, you should be able to manually download one of those versions from http://archive.ubuntu.com/ubuntu/pool/main/b/bash/ and install it. I wonder how many vulnerable boxes there are that won't get these updates because Ubuntu stops support after 9 months. There must be tons of boxes running 13.10, it's not even a year old yet.
----------------------------------------------------------
amd64
wget archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.2-2ubuntu2.3_amd64.deb
sudo dpkg -i bash_4.2-2ubuntu2.3_amd64.deb
----------------------------------------------------------
i386
wget archive.ubuntu.com/ubuntu/pool/main/b/bash/bash_4.2-2ubuntu2.3_i386.deb
sudo dpkg -i bash_4.2-2ubuntu2.3_i386.deb
$ apt-cache show debian-goodies
<SNIP>
checkrestart - Help to find and restart processes which are using old
versions of upgraded files (such as libraries)apt-get update
apt-get install --only-upgrade bash
fwiw, Linode's mirrors are up with the latest version yet Digital Ocean's are not. I lose faith in DO everytime I remote into my VM. They just seen like an amateurish shop.
edit: and how do I know if I am still vulnerable?
edit2: ok, this is the test
env x='() { :;}; echo vulnerable' bash -c "echo this is a test"
WIll tell you which version of bash is installed, for precise you should have bash 4.2-2ubuntu2.2
ayourtch@mcmini:~/bash-patch$ ls
bash_4.2-2ubuntu2.2_amd64.deb bash-builtins_4.2-2ubuntu2.2_amd64.deb t
ayourtch@mcmini:~/bash-patch$ dpkg -x bash_4.2-2ubuntu2.2_amd64.deb t
ayourtch@mcmini:~/bash-patch$ diff -c t/bin/bash /bin/bash
Binary files t/bin/bash and /bin/bash differ
ayourtch@mcmini:~/bash-patch$ t/bin/bash --version
GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
ayourtch@mcmini:~/bash-patch$ /bin/bash --version
GNU bash, version 4.2.25(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
ayourtch@mcmini:~/bash-patch$ sha1sum t/bin/bash
9eeed02173db163b013933eff3b8c6aa3697f67f t/bin/bash
ayourtch@mcmini:~/bash-patch$ sha1sum /bin/bash
3384fadf84146a4d4b6b7f529f615e9947b4ac99 /bin/bash
ayourtch@mcmini:~/bash-patch$you're probably not directly vulnerable for this very vuln, but then again, maybe you are. with enough vulns it gets complex enough to check that its easier to just update with all the security updates..
Related to that, does anyone else know if upgrading bash will require a restart of other services kind of like upgrading openssl requires restarting things?
I don't think it will, for a couple of reasons. OpenSSL is integrated into other services as a library, while bash would be called as an external application. I also noticed that once I upgraded bash, the proof of concept stopped working in a terminal I opened prior to the upgrade.
[citation needed] because that doesn't sound possible.
I just tested this on Ubuntu 14.04 - it's vulnerable.
Why don't you explain in plain english exactly why you feel this is the case? "Drop-everything" in other words (or even close to that). Give some scenarios. After all anyone who knows a great deal doesn't need that advice the people who need that advice are ones that don't know enough to know what the impact of this is. [1]
Perhaps you could clarify with some examples of why (see child comment "So, as a amateur sysadmin of a decently popular side project") you think this applies to anyone who is "responsible for the security of any system"?
[1] Me for one because I'm not seeing the "Drop everything" priority for any of the systems that I have control over given the way they are configured. That said I'd like to hear more of course.
Helpful?
"is potentially an unauthenticated GET request"
Are you saying that if you don't have a web server that allows "get" requests (only posts) then this exploit is not an issue at all?
You can learn by experience, or you can try to leach the wisdom of others.
Usually no. This exploit should be vulnerable to any HTTP method. "unathenticed GETs" are the lowest security level of HTTP calls, so if they can be used as an attack vector, you should pay attention.
I ask because I've seen SSIDs with meaningful characters ()<>;? cause trouble with some network managers. I presumed at the time that this was due to the SSID string being passed as an argument to some script.
I've encountered this on my old Android phone and my old Debian laptop. I encountered it often because a friend of mine used to have an emoticon in the SSID for his home router. (Really annoying! I couldn't connect to anything when his router was in range.)
Note: it could very well have been a different problem. I didn't investigate.
Unauthenticated GET requests were just an example of something that can invoke this behavior. If you have any network-enabled service that's capable of spawning a shell, you can have attack vectors open.
Possible vectors include things like DHCP clients, SSH, web servers, etc. Lots of things open shells for reasons you wouldn't intuitively expect. It's very likely that there are many creative vectors for exploitation that will be discovered in the coming hours.
(Note I'm not claiming this is the "worst bug ever"... there's stiff competition for that claim. But most of the rest of the "worst bug ever"s I can think of are some point that failed, some particular thing you could do for full root access or something. I can't think of anything else with this sheer staggering surface area.)
Web servers pass information about the HTTP client to CGI scripts using environment variables. A CGI script written in bash would be vulnerable to arbitrary command execution if any HTTP header contained the vulnerable string.
GET / HTTP/1.0
User-Agent: () { :; }; rm -rf /
ssh git@example.com '() { :; }; rm -rf /'
Edit: as others have pointed out, even non-bash CGI scripts that use a shell to run external processes are vulnerable For example, system("/usr/local/bin/whatever --some-fixed-option") would normally be considered safe since there's no untrusted data in the command-line (although perhaps it would be considered poor design), but it'll run a shell to do the whitespace splitting. If that shell is bash....
You're killin' me here. If you expose a shell script directly to the network, you're exposing a shell and deserve to be pwned.
The scope of the risk is limited to script that you write, whether bash or Python.
#!/bin/bash
PHPRC=$PWD/../etc/php5
export PHPRC
umask 022
export PHP_FCGI_CHILDREN
PHP_FCGI_MAX_REQUESTS=99999
export PHP_FCGI_MAX_REQUESTS
SCRIPT_FILENAME=$PATH_TRANSLATED
export SCRIPT_FILENAME
exec /usr/bin/php5-cgi
So considering there are other variables in there that can be manipulated it would be possible to own a large chunk of servers on the Internet. However I'm not sure if there is caveat and I had hoped that someone can help me.
Edit: Looks safe. These variables are not even there. It's just an outdated script.
There is a reason PHP is to be kept away and not touched with a ten meter stick, it seems to spawn a shell for weird reasons, I dont think python or groovy apps do that. They're safe, unless you somewhere specifically invoke System.getRuntime().run("bash");
That's a one-liner in Groovy, written in the Java style of chained method calls, which is the direct equivalent of spawning a shell in non-JVM languages, so that's not an argument for using Groovy instead of PHP.
That's nice. I like this song.