On the theory that it is more likely to help HNers than the bad guys: <a href="http://httpd.apache.org/docs/2.2/mod/mod_ssl.html" rel="nofollow">http://httpd.apache.org/docs/2.2/mod/mod_ssl.html</a> . Note in particular the part about StdEnvVars. The docs say it is off by default, but it is actually on in a lot of common deployment scenarios, for example if most of your apache configs were sourced from the big "apt-get install foo bar baz" line everyone copies from a blog post to get a working LAMP installation on an Ubuntu box.<p>I have not POCed this yet, but if I were trying to, I'd first try to make a client certificate with a highly non-standard Distinguished Name. It doesn't particularly matter if it fails validation as long as it doesn't fail in such a way that Apache dies before passing your information deeper into the guts of the web app.<p>After that point you're just looking for e.g. any page or library in the web app you can coerce to do a system() call or similar. While I was poking around in my own apps something like system(...) in Ruby on Ubuntu actually called /bin/sh rather than bash, but I think that is probably not the case for every combination of stack and distro.
Always protect your OpenVPN instances with tls-auth, especially if your instance accepts connections from any IP. It prevents the SSL negotiation from even occurring if it doesn't match. It would have protected you from heart bleed, and it protects against shell shock.<p>There is no downside to using it. However, keep in mind that the key file is shared across all clients, so you probably want to change it periodically depending upon how much you trust your clients not to become hostile. You could run multiple server instances on different ports/IPs to subdivide your client base, or when rolling out a new key.
Maybe a small note, but the variable needs to start with the <i>bytes</i> "() {", not the <i>characters</i>.<p>For example, () {̀ also triggers the parsing code. That's a ` over the { using Unicode.<p>FWIW, I haven't been able to actually exploit it this way, but referencing that variable in the new shell generates errors, so there might be something there:<p>bash: () {̀ :;}; echo vuln2: invalid variable name for name reference
One thing that'd be somewhat useful, with respect to #2 ("It must invoke bash"), is to separate it into those which specifically invoke bash, versus those that invoke /bin/sh. If bash is not installed as /bin/sh, as is the case on Debian and Ubuntu, do any of these (inetd, exim, etc.) still explicitly call it? Put differently, is this mainly an issue for distributions that ship bash as /bin/sh? Or do users of distributions like Debian also need to worry about common system services setting bash shell variables?<p>Maybe I'll try to answer that by pulling a bunch of Debian source packages and grepping for explicit calls to bash...
For Mac OS X, until Apple releases a software update, I've applied the original CVE-2014-6271 (shellshock) patch and the CVE-2014-7169 patch. Repository and instructions to reproduce without trusting me are located here:
<a href="https://github.com/ido/macosx-bash-92-shellshock-patched" rel="nofollow">https://github.com/ido/macosx-bash-92-shellshock-patched</a><p>Binary releases are here:
<a href="https://github.com/ido/macosx-bash-92-shellshock-patched/releases" rel="nofollow">https://github.com/ido/macosx-bash-92-shellshock-patched/rel...</a>
...including a .pkg file that can be installed with a double-click.<p>Instruction here:
<a href="https://github.com/ido/macosx-bash-92-shellshock-patched/blob/master/README.md" rel="nofollow">https://github.com/ido/macosx-bash-92-shellshock-patched/blo...</a>
You missed one of the big ones, DHCP. dhclient calls dhclient-script with attacker controlled environment variables, and on several Linux distros I checked, dhclient-script explicitly uses Bash, so even Debian and Ubuntu, which use dash as sh, are vulnerable.
rather than adding fixup to these (which arent all exactly directly exploitable, and sometimes have dodgy POCs), it'd be nice if we stopped calling the shell at all and when necessary, always wipe the env entirely and parse the user input by allowing a specific white list.<p>these methods were used a decade ago and programs not doing stuff like clearing the env were seen as poorly made programs in need of rewrite. Unfortunately that has changed.
I wonder if anyone has thought of any indirect vectors? Imagine a Windows based virus that can scan a private network and use the shellshock exploit to infect never-before-seen unix devices with a HTTP service?
So assuming it's an online EC2 server not-updated LAMP stack with an empty cgi folder and a lone html page with hello world. Is that vulnerable to bash exploitation in any way?
I feel like the only reasonable thing to do now is to capture all traffic going to a web server and analyze every field for that's that eventually become env vars.
This of course assumes that bash is set as the default shell for those users all those programs run under. None of my systems have bash installed, thus they aren't vulnerable. FreeBSD by default does not ship with bash, and unless it is specifically installed for 3rd party software use, it is not required for anything, and certainly won't be found as /bin/sh...<p>Shell shock is being blown out of proportion, people are worried local machines they use to browse internet are going to get popped when in reality it is only really Linux machines that have bash as the default shell that should be worried.
<a href="https://access.redhat.com/articles/1200223" rel="nofollow">https://access.redhat.com/articles/1200223</a><p>CUPS probably too, but no POC seen yet
suphp <i></i> might <i></i> be exploitet, but only with stupid settings<p><a href="https://8ack.de/guides/suphp_shellshock" rel="nofollow">https://8ack.de/guides/suphp_shellshock</a>
Somewhat ironic for all the noise made about qmail that many configurations of it are vulnerable. I wonder if Bernstein will be paying out that $1000 reward, and if so, to who<p>See section 1.3:<p><a href="http://cr.yp.to/qmail/qmailsec-20071101.pdf" rel="nofollow">http://cr.yp.to/qmail/qmailsec-20071101.pdf</a>