Understanding, exploiting and preventing CVE-2014-6271: remote code execution through bash

Well today I’m going to write a short note about this security issue which is now public. The issue has been tested and fixed on Gentoo systems and given the type it does affect even hardened systems.

TL;DR: export LC_AHAHAHA='() { ignored; }; /usr/bin/exploit’; then git or ssh into the place. You may also affect anything using user provided environment variables and bash. for example CGI To prevent it, forbide users from passing environment (in ssh the directive is AcceptEnv, CGI systems are harder to fix and would need variable value filtering or using a differen/fixed shell).

The issue by itself is quite simple, bash passes around functions as environment variables to child processes. This by itself can cause issues as you may create functions replacing genuine programs and thus overcome the forced command limitations imposed by ssh. But this is not obviously the bug being though.

CVE-2014-6271 is about a more serious issue in this scheme: bash will “eval” the variable so it will try to execute commands after the closing brace. To you, this means that if you pass around user data as environment variables to a bash shell the user can execute any command they wish although this may eventually lead to a crash. In particular, the chain doing so is () {

The exploit is quite simple:

• For ssh based services:
  • export LANG='() { a; }; /usr/bin/payload’ LC_MESSAGES='() { ; }; /usr/bin/payload’
  • Enable SendEnv in your ssh client
  • ssh around
• For CGI bases services set variables passed to the script as ‘() { ; }; /usr/bin/payload’

The ways to mitigate the attack until the fix can be deployed are as follows:

• In SSH: disable AcceptEnv globally (as it will not be possible to disable it per user) and set it only for users with shell access using match directives.
• In CGI scripts and other environment passing solutions: filter around user input starting with the known pattern () { before passing it to the script
• In general: try to use an alternative shell until the issue is fixed in your deployment, in particular busybox’s bb seems to not be affected by this issue.
• As usual, the best solution is to deploy an updated version of bash if you can. In Gentoo, the latest such version is =app-shells/bash-4.2_p48-r1 but the full list is provided below.

Finally this attack may cause the bash prompt to crash so it may be noticed in the server logs (at least with Hardened kernels). Logs will look as follows:

[3980188.632282] bash[28426]: segfault at 0 ip 0000004c619b8a13 sp 000003b8887bfab0 error 4 in bash[4c6196d000+d1000]
[3980188.632347] grsec: From 127.0.0.1: Segmentation fault occurred at            (nil) in /bin/bash[bash:28426] uid/euid:115/115 gid/egid:122/122, parent /usr/sbin/sshd[sshd:28421] uid/euid:115/115 gid/egid:122/122
[3980188.632421] grsec: From 127.0.0.1: denied resource overstep by requesting 4096 for RLIMIT_CORE against limit 0 for /bin/bash[bash:28426] uid/euid:115/115 gid/egid:122/122, parent /usr/sbin/sshd[sshd:28421] uid/euid:115/115 gid/egid:122/122

Edit 2: seems the fixes published originally don’t fully fix the issue in bash (thanks for the heads up Marvin). You can test if you are affected by executing something like: date -u > file1; env -i X='() { (a)=< \' bash -c 'file1 cat' For Gentoo/Gentoo Hardened users the following versions of bash  have fixed the issue and are being stabilized: