43

I have an Apache webserver running, and with the recent news of the Shellsock exploit against bash I was wondering if my webserver is vulnerable. I don't think it is, but I want to make sure I'm not mistaken.

I don't use any bash CGI intentionally on the server, it is running some PHP stuff using mod_php and a Python WSGI site. But I'd like to be sure that none of the software running on the server is using CGI without me expecting it.

How can I make sure that my webserver is not vulnerable?

user56147
  • 431
  • 1
  • 4
  • 4
  • 1
    You are potentially vulnerable if you have a vulnerable shell **AND** a way for attackers to manipulate environment variables (indirectly or otherwise). – MattBianco Sep 25 '14 at 10:46

4 Answers4

29

Aside from CGI, one overlooked use of sh is in exec() calls, or through the use of system() and popen(), on most Linux systems this means bash. The exec() family of calls are often used with "/bin/sh -c" to provide various features like shell redirection, pipelines or even just argument expansion when invoking processes.

Apache uses exactly this (via APR, see the use of SHELL_PATH in apr/threadproc/unix/proc.c) when you use piped logs, and also in other circumstances such as external output filters (via ExtFilterDefine), and processing of #exec cmd SSI includes. This behaviour almost certainly applies to many third party modules too.

The best steps to take to secure your web server:

  • patch or upgrade your bash package (if you do this yourself make sure there are no stray sh instances, check for sh in any manually set up chroots too)

  • run Apache in a chroot, use a minimal /bin/sh if and only if it is required:

    • in Apache httpd 2.2 switch from using "|" to "||" in piped logs, this removes the need for /bin/sh (available since Apache 2.2.12)
    • in Apache httpd 2.4 make sure you're not using "|$" in piped logs, this reverts to the httpd.2.2 behaviour. 2.4 supports | and ||, neither use /bin/sh

  • make sure the default CGI scripts are disabled, double check from the top-level Options (e.g. <Directory /> down for ExecCGI

  • consider mod_security if you're not already using it. Red Hat have provided some rules which can be used to log and clean up the environment in KB article 1212303.

You may also consider using "#!/bin/sh -p" in scripts, this forces bash into privileged mode, this prevents importing functions from the environment (along with other changes). This might help if you have vulnerable CGI scripts on a system, but no patch and no compiler. This might not work on Debian and derived systems, so check carefully.

(Also, if /bin/sh is bash, don't blindly replace it with something else, it might affect your startup scripts.)

Any application code that runs via CGI (other than bash scripts), or under Apache modules (Python and PHP in your case) may also play a part in this. If any variable can be sufficiently controlled by an attacker (URI-encoding may be a challenge), and if the application uses /bin/sh when invoking processes, and if those variables are preserved while doing so, then you might have a problem.

If you are running a contemporary Linux system, but you have not set up a chroot or some other container for apache, you should be able to use unshare and a bind mount to replace /bin/sh when starting Apache (or any other service). 

unshare -m -- sh -c "mount --bind /usr/local/bin/bash /bin/sh && 
    /usr/local/apache2/bin/apachectl start"

The advantages to this are

  • less risk of breaking things, since you can selectively replace bash
  • you can log and audit attempts to invoke sh more easily

(What you cannot easily do with this is write a bash script as a wrapper to inspect and log suspicious variables, you'll need to use something else of course...)

If you're running auditd on Linux, you can easily watch the use of /bin/sh by adding a couple of rules to audit.rules and reloading:

-w /bin/sh                -p x
-w /bin/bash              -p x

(I need both, since sh is a symlink to bash)

Red Hat have published an alternate approach, a runtime "fix" which you can use with LD_PRELOAD, you can find that in the advisory. This could also be adapted to log dubious variables, if required. Given that there are currently questions over the completeness of the patches so far, this solution is probably a good short-term fix for Apache at least.

You can also find more general Apache hardening tips here: Apache Server Hardening

Community
  • 1
mr.spuratic
  • 7,937
  • 25
  • 37
  • 1
    bash is still unsecure see CVE-2014-7169. Use of zsh is encouraged as should not be affected. – Lesto Sep 25 '14 at 11:43
  • Bear trap: SSI (includes) using `#exec cmd` start life with a "/bin/sh". CGI scripts do not have this extra layer, so a `#!/bin/ksh` CGI script is safe AFAICT (tested under httpd-2.2 only). – mr.spuratic Sep 25 '14 at 17:53
9

According to Redhat advisory:

mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.

Read more about it from : https://access.redhat.com/node/1200223

void_in
  • 5,541
  • 1
  • 20
  • 28
shaomoon
  • 91
  • 1
  • 1
    This article also shows how to test if bash is vunerable (Which is what the op is asking). $ env x='() { :;}; echo vulnerable' bash -c "echo this is a test" – squareborg Sep 25 '14 at 10:14
  • 6
    Red Hat's "*do not use environment variables and we believe they are not affected*" is misleading IMHO: the modules themselves might not be direct vulnerable, but they are almost certainly running code which might be. Consider if the modules might create/preserve problematic environment content, and if they pass this to a vulnerable shell. Have a peek at perl's `Perl_do_exec3()`, PHP's `proc_open()` or Python's `pipes` or `subprocess`. – mr.spuratic Sep 25 '14 at 11:54
  • @Shutupsquare - thanks, this is what I came here for. – ajh158 Sep 25 '14 at 13:04
1

Secure bash and you have secured the box. There are patches available in most distributions or you could compile and patch it yourself if you run a distribution that is not yet patched.

Lighty
  • 2,368
  • 1
  • 23
  • 36
Andrew
  • 47
  • 1
1

If you are not sure you can disable the cgi module sudo a2dismod mod_cgi or remove LoadModule in httpd.conf. As shaomoon mentioned mod_php, mod_perl and mod_python are not effected.

Anyway you should simply install the patch. If your bash is not vulnerable your apache will also be protected from this attack.

Community
  • 1
PiTheNumber
  • 5,394
  • 4
  • 19
  • 36
  • I don't think that's a real iptables rule. I get ```bad argument 'using'```. – sep332 Sep 25 '14 at 14:02
  • No that is not a rule, You need to add the rule to your chain (i.e: -A INPUT) and assign an action (e.g -j DROP) – HEX Sep 25 '14 at 14:33