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.
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.
fascgi_params puts a lot of attacker controlled data into "environment variables", but depending on php.ini's variables_order setting those might not actually go into what the rest of the word thinks is an environment variable (and hence not get passed to subprocesses, which is the point of the exercise). If php.ini's variables_order includes an "E", then the environment variable QUERY_STRING (among other things) will include attacker-chosen data. variables_order does include E by default, but does not in the php.ini which ships with the obvious apt-get commands for e.g. Ubuntu.
output -> https://gist.github.com/anonymous/ea60dc2915eccf0b803e
index.php -> https://gist.github.com/anonymous/883b989caba4156e47b6
but maybe suphp seems a little more suspicious?
/etc/suphp/suphp.conf ...
[handlers] ;Handler for php-scripts application/x-httpd-suphp="php:/usr/bin/php-cgi"
;Handler for CGI-scripts x-suphp-cgi="execute:!self"
It's really impossible to understand you, but fastcgi_params does not put attacker controlled data into environment variables (without the quotes). That much is clear so normal usage of fastcgi is not in danger.
Maybe I'll try to answer that by pulling a bunch of Debian source packages and grepping for explicit calls to bash...
I've tried doing explicit grepping for bash throughout various source code, but it's a lot of work to then trace back if that particular script is ever executed by some chain of commands that ultimately originated from something networked which sets environment variables to attacker controlled values.
Debian switched /bin/sh to link to dash a while back, but some maintainers decided to simply change the #!/bin/sh at the top of the shell scripts in their packages to #!/bin/bash rather than remove the bashisms. dhclient is the worst offender in the current kerfuffle, but I'm sure there are others.
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.
For example, a hypothetical encryption library might be a wrapper around /usr/bin/gpg or /usr/bin/openssl, and to avoid having arguments show up in ps or top, it might pass arguments as environment variables. Later a secure e-mail program might use that library to validate a signature from an e-mail, and pass signature data in an environment variable. So that's MacOSX and Fedora owned with /bin/bash as /bin/sh. Say the encryption library used a script written in Bash to do some other processing. That's BSD owned.
It's unclear how often shellouts happen within OSX for various operations.
It's entirely possible I forgot something. I haven't built an RPM in years and didn't do it often in the first place. I almost didn't bother now except I can't entirely exclude the possibility that two RHEL3 servers that aren't going anywhere might have an attack vector hidden in them somewhere.
Edit: Changed link to fixed gist.
See section 1.3:
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.
As it is, it provides a clear and easy to follow path to a minimally viable setup, but only mentions many additional security parameters (tls-auth, running as unpriviledged user, chroot, increasing key size) under "Hardening OpenVPN Security", very far down the page, where people probably miss it. And this, even though some of these elements vastly increase the security with little to no downside.
[0] https://openvpn.net/index.php/open-source/documentation/howt...
Binary releases are here: https://github.com/ido/macosx-bash-92-shellshock-patched/rel... ...including a .pkg file that can be installed with a double-click.
Instruction here: https://github.com/ido/macosx-bash-92-shellshock-patched/blo...
http://apple.stackexchange.com/a/146851
It provides a one-step copy and paste into the terminal to download, patch and compile bash from apple.com and gnu.org.
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.
If a program simply slurps in user input without doing any basic validation according to published RFCs then there's a bug in that program.
For example, () {̀ also triggers the parsing code. That's a ` over the { using Unicode.
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:
bash: () {̀ :;}; echo vuln2: invalid variable name for name reference
CUPS probably too, but no POC seen yet
