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.

What is this software that one fifth of companies run

A ridiculously popular application, written in PHP, which is widely useful to software companies (among others).

why is technically savvy in scare quotes

I originally wrote "startup" then thought "Actually, this is deployed by a lot of people who aren't startups or who are only arguably startups, hmm, that is an unproductive debate, let's just say what I mean then move on."

some veiled reference to something called spray-and-pray?

Many applications have a well-known set of URLs associated with them. A spray-and-pray exploit is one which you can just fire at a well-known URL at every machine which responds to port 80 in IP4 space. The reason I am not identifying the vulnerable software written in PHP is that it would allow any script kiddie smart enough to text edit the existing exploit scripts to exploit that software as an additional vector.

fastcgi_params does not put attacker controlled data into environment variables (without the quotes)

I'm absolutely positive that fastcgi_params does indeed clobber $_ENV with attacker supplied data if PHP is configured as described above. I am less strongly confident that some configurations of PHP will allow $_ENV to get to at least some subprocesses. I am absolutely confident that some configurations of PHP will not allow you to set $_ENV nor set environmental variables. I have figured out ways to configure it which put the fastcgi_params in $_SERVER but not $_ENV and, separately, in $_ENV but not in environment variables passed to subprocesses. I'm aware of a PHP command which the documentation suggests defaults to passing $_ENV as actual environment variables to subprocesses but which I have not been able to verify actually works as the documentation says, due to it being 6 AM in the morning local time and me having insufficient motivation to continue finding more reasons to justify the conclusion that this bug is very, very bad news and bash needs to get patched immediately everywhere.

it does

https://gist.github.com/anonymous/ea60dc2915eccf0b803e

https://8ack.de/guides/suphp_shellshock

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...

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

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.

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, 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.

I'll also provide a list of files from /usr/bin that are actually implemented using Bash (from a Linux Mint system). Anything using these with user-controlled environment variable values is vulnerable:

    $ grep -nR '#!.*bash' * | grep :1:
    apg:1:#!/bin/bash
    aptitude-create-state-bundle:1:#!/bin/bash
    aptitude-run-state-bundle:1:#!/bin/bash
    banshee:1:#!/usr/bin/env bash
    cautious-launcher:1:#!/bin/bash
    checkinstall:1:#!/bin/bash
    cinnamon2d:1:#!/bin/bash
    dns-fix:1:#!/bin/bash
    editdiff:1:#!/bin/bash
    fakenect:1:#!/bin/bash
    fakeroot:1:#!/bin/bash
    fakeroot-sysv:1:#!/bin/bash
    fakeroot-tcp:1:#!/bin/bash
    gnome-www-browser:1:#!/bin/bash
    google-chrome:1:#!/bin/bash
    google-chrome-stable:1:#!/bin/bash
    gufw-pkexec:1:#!/bin/bash
    im-config:1:#!/bin/bash -e
    init-checkconf:1:#!/bin/bash
    installwatch:1:#!/bin/bash
    inxi:1:#!/bin/bash
    itweb-settings:1:#!/bin/bash
    javaws:1:#!/bin/bash
    lcf:1:#!/bin/bash
    ldd:1:#! /bin/bash
    libtool:1:#! /bin/bash
    lua2dox_filter:1:#!/bin/bash
    lzcmp:1:#!/bin/bash
    lzdiff:1:#!/bin/bash
    lzegrep:1:#!/bin/bash
    lzfgrep:1:#!/bin/bash
    lzgrep:1:#!/bin/bash
    lzless:1:#!/bin/bash
    lzmore:1:#!/bin/bash
    mate-help:1:#!/bin/bash
    mintBackup:1:#!/bin/bash
    mint-fortune:1:#!/bin/bash
    mintupload:1:#!/bin/bash
    mintupload-manager:1:#!/bin/bash
    muinshee:1:#!/usr/bin/env bash
    mysqld_safe:1:#!/bin/bash
    p7zip:1:#!/bin/bash
    pipelight-plugin:1:#!/usr/bin/env bash
    pnmindex:1:#!/bin/bash
    policyeditor:1:#!/bin/bash
    ppmquantall:1:#!/bin/bash
    rarian-sk-config:1:#!/bin/bash
    rarian-sk-extract:1:#!/bin/bash
    rarian-sk-rebuild:1:#!/bin/bash
    rarian-sk-update:1:#!/bin/bash
    scrollkeeper-config:1:#!/bin/bash
    scrollkeeper-extract:1:#!/bin/bash
    scrollkeeper-rebuilddb:1:#!/bin/bash
    scrollkeeper-update:1:#!/bin/bash
    sotruss:1:#! /bin/bash
    steam:1:#!/usr/bin/env bash
    su-to-root:1:#!/bin/bash
    tomboy:1:#!/usr/bin/env bash
    tzselect:1:#!/bin/bash
    ucf:1:#!/bin/bash
    ucfr:1:#! /bin/bash
    usb-devices:1:#!/bin/bash
    X11/scrollkeeper-config:1:#!/bin/bash
    X11/fakenect:1:#!/bin/bash
    X11/lzgrep:1:#!/bin/bash
    X11/cautious-launcher:1:#!/bin/bash
    X11/xzdiff:1:#!/bin/bash
    X11/aptitude-create-state-bundle:1:#!/bin/bash
    X11/mint-fortune:1:#!/bin/bash
    X11/mate-help:1:#!/bin/bash
    X11/scrollkeeper-extract:1:#!/bin/bash
    X11/fakeroot:1:#!/bin/bash
    X11/editdiff:1:#!/bin/bash
    X11/lzdiff:1:#!/bin/bash
    X11/apg:1:#!/bin/bash
    X11/mintupload-manager:1:#!/bin/bash
    X11/gnome-www-browser:1:#!/bin/bash
    X11/ucfr:1:#! /bin/bash
    X11/lzcmp:1:#!/bin/bash
    X11/libtool:1:#! /bin/bash
    X11/im-config:1:#!/bin/bash -e
    X11/xzmore:1:#!/bin/bash
    X11/mintupload:1:#!/bin/bash
    X11/xzegrep:1:#!/bin/bash
    X11/javaws:1:#!/bin/bash
    X11/xchat-systray:1:#!/bin/bash
    X11/itweb-settings:1:#!/bin/bash
    X11/dns-fix:1:#!/bin/bash
    X11/su-to-root:1:#!/bin/bash
    X11/checkinstall:1:#!/bin/bash
    X11/usb-devices:1:#!/bin/bash
    X11/rarian-sk-extract:1:#!/bin/bash
    X11/tzselect:1:#!/bin/bash
    X11/google-chrome-stable:1:#!/bin/bash
    X11/xzcmp:1:#!/bin/bash
    X11/xzgrep:1:#!/bin/bash
    X11/pipelight-plugin:1:#!/usr/bin/env bash
    X11/lcf:1:#!/bin/bash
    X11/scrollkeeper-rebuilddb:1:#!/bin/bash
    X11/banshee:1:#!/usr/bin/env bash
    X11/cinnamon2d:1:#!/bin/bash
    X11/xzfgrep:1:#!/bin/bash
    X11/muinshee:1:#!/usr/bin/env bash
    X11/lzfgrep:1:#!/bin/bash
    X11/mintBackup:1:#!/bin/bash
    X11/tomboy:1:#!/usr/bin/env bash
    X11/fakeroot-sysv:1:#!/bin/bash
    X11/aptitude-run-state-bundle:1:#!/bin/bash
    X11/gufw-pkexec:1:#!/bin/bash
    X11/init-checkconf:1:#!/bin/bash
    X11/x-www-browser:1:#!/bin/bash
    X11/lzegrep:1:#!/bin/bash
    X11/rarian-sk-update:1:#!/bin/bash
    X11/sotruss:1:#! /bin/bash
    X11/ldd:1:#! /bin/bash
    X11/ppmquantall:1:#!/bin/bash
    X11/rarian-sk-rebuild:1:#!/bin/bash
    X11/xzless:1:#!/bin/bash
    X11/rarian-sk-config:1:#!/bin/bash
    X11/p7zip:1:#!/bin/bash
    X11/google-chrome:1:#!/bin/bash
    X11/lzmore:1:#!/bin/bash
    X11/fakeroot-tcp:1:#!/bin/bash
    X11/mysqld_safe:1:#!/bin/bash
    X11/ucf:1:#!/bin/bash
    X11/policyeditor:1:#!/bin/bash
    X11/lzless:1:#!/bin/bash
    X11/lua2dox_filter:1:#!/bin/bash
    X11/installwatch:1:#!/bin/bash
    X11/inxi:1:#!/bin/bash
    X11/scrollkeeper-update:1:#!/bin/bash
    X11/steam:1:#!/usr/bin/env bash
    X11/pnmindex:1:#!/bin/bash
    xchat-systray:1:#!/bin/bash
    x-www-browser:1:#!/bin/bash
    xzcmp:1:#!/bin/bash
    xzdiff:1:#!/bin/bash
    xzegrep:1:#!/bin/bash
    xzfgrep:1:#!/bin/bash
    xzgrep:1:#!/bin/bash
    xzless:1:#!/bin/bash
    xzmore:1:#!/bin/bash

I just grepped all the Makefiles in my ports tree for 'shells/bash', and came up with 48 matches. This includes ports that depend on bash at build time, at test time, and at runtime. So for people who just use packages, the number of things that are going to pull in bash (as a runtime dep) is lower than that.

We have many of the same programs you have, but they do not use bash. For example, all your executables that start with xz or lz. I have them, most of them anyway, but they use /bin/sh, not /bin/bash.

I use BSD on the desktop, and out of the three hundred packages I have installed, none have pulled bash in as a dep. I don't have bash, I haven't had it for years.

http://www.freshports.org/shells/bash

It's unclear how often shellouts happen within OSX for various operations.

CUPS probably too, but no POC seen yet

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.

https://8ack.de/guides/suphp_shellshock

See section 1.3:

http://cr.yp.to/qmail/qmailsec-20071101.pdf

The only reasonable policy for a shell to follow is to be entirely input-agnostic and never execute code based on the contents of an environment variable (regardless of which RFCs the contents conform to).

Even though bash shouldn't have executed the code, better input validation and RFC conformance in qmail could have prevented exploitation of bash. You know, defense-in-depth.