Bashbug: Remote Code Execution Through Bash (CVE-2014-6271)

Today some big news about a flaw that was found in the way Bash evaluated certain specially crafted environment variables by Redhat.

See for more information here:

An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue. This is OS wide even on Mac OSX.

Is it bad?

OMFG YES THE INTERNET HAS STOPPED WORKING LULLZZ!!!111. No not really, the vulnerability looks pretty awful at a glance, but most systems with bash installed will not be remotely exploitable as a result of this issue. In order to exploit this flaw, an attacker would need the ability to send a malicious environment variable to a program interacting with the network and this program would have to be implemented in bash, or spawn a sub-command using bash. My link to the Red Hat blog post goes into detail on the conditions required for an attack. But please do not underestimate the impact of this bug. It is a problem. Period.

As a result, this vulnerability is exposed in many contexts, for example:

  • ForceCommand is used in sshd configs to provide limited command execution capabilities for remote users. This flaw can be used to bypass that and provide arbitrary command execution. Some Git and Subversion deployments use such restricted shells. Regular use of OpenSSH is not affected because users already have shell access.
  • Apache server using mod_cgi or mod_cgid are affected if CGI scripts are either written in bash, or spawn subshells. Such subshells are implicitly used by system/popen in C, by os.system/os.popen in Python, system/exec in PHP (when run in CGI mode), and open/system in Perl if a shell is used (which depends on the command string).
  • PHP scripts executed with mod_php are not affected even if they spawn subshells.
  • DHCP clients invoke shell scripts to configure the system, with values taken from a potentially malicious server. This would allow arbitrary commands to be run, typically as root, on the DHCP client machine.
  • Various daemons and SUID/privileged programs may execute shell scripts with environment variable values set / influenced by the user, which would allow for arbitrary commands to be run.
  • Any other application which is hooked onto a shell or runs a shell script as using bash as the interpreter. Shell scripts which do not export variables are not vulnerable to this issue, even if they process untrusted content and store it in (unexported) shell variables and open subshells.

Fix the vulnerability

But how can you know whether you’re vulnerable or not?
Enter the following in a terminal or command shell:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

And you see this? Then you’re vulnerable.

After updating to the new release 4.3.024-1 (for Example on ArchLinux on my host system) you’ll see an error that means it cannot execute the shell command anymore:

Hereby some command for different distro’s how to fix this issue. But beware, the patch is incomplete, if will not cover up the whole bug:

  • CentOS: yum update bash
  • Ubuntu/Debian: sudo apt-get update && sudo apt-get install bash
  • FreeBSD: sudo pkg update (patched version not available on time of writing)
  • ArchLinux: pacman -S bash
  • Fedora: su -c yum update bash
  • OpenBSD: sudo pkg_add -i -v bash

Anyother way of mitigating this bug (when patching isn’t possible) is by manually compiling bash_ld_preload.c, but this has been tested very limited and might cause issues. Checkout this URL:

Many online testingtools are popping up on the internet, Erratec has started a mass IP-address scan to check percentages of vulnerable systems. Exploits in the wild are also being posted at this moment. Even later today you can expect a module for Metasploit too ;). Good day.