Shell Shock Exploitation Vectors

This is an incomplete catalog of potential exploitation vectors for CVE‒2014‒6271, or “Shell Shock”. I’m posting this hastily and will update it continuously with new findings. Please leave a comment if you can think of any vectors not listed here.

For a service to be vulnerable to Shell Shock, three conditions must be met:

  1. It must set an environment variable whose value (not necessarily name) is attacker-controlled, and particularly must be made to begin with () {.
  2. It must invoke bash.
  3. The system must be running a vulnerable version of bash.

Throughout this post I will take condition #3 as assumed, and examine #1 and #2. In all cases, patching bash is sufficient to close the vulnerability; no updates or configuration changes to the particular service providing the exploit vector are necessary.

All of these assessments are the result of spelunking through documentation and source code. I have not attempted proof-of-concept for any of them.

Well-known vectors (CGI and SSH)

Exploitation through bash-based CGI scripts and through SSH has been discussed at length in the original advisory and throughout the blogosphere, and I won’t address it further in this post.

Inetd

Inetd implementations which comply with the UCSPI protocol will set $TCPREMOTEHOST to the RDNS PTR record for the connecting host’s IP address, and $TCPREMOTEINFO to the response from any IDENT server running on the connecting host. Implementations which support this behavior include tcpserver (always) and GNU inetd (when invoked with ‑‑environment ‑‑remote). OpenBSD inetd and xinetd do not set any attacker-controlled environment variables, so OpenBSD inetd and xinetd are not vulnerable.

Most users of tcpserver use it run other DJBware such as qmail-smtpd and axfrdns. In typical configurations, tcpserver executes these programs directly without invoking the shell, but it is possible that some sysadmins wrap those programs with a bash script. If so, such tcpserver services are vulnerable.

I have no idea who uses GNU inetd, or for what, or how common it is to invoke it with ‑‑environment ‑‑remote.

Mail services

Probably a majority of UNIX mail servers are exposed to Shell Shock somewhere in their often-lengthy chain of mail-handling programs.

Exim

Exim sets a number of attacker-controlled environment variables when invoking the pipe transport. Whether or not it uses the shell invoke it is determined by the use_shell option. Even if use_shell is not set, the program invoked is often a shell script. Therefore, many Exim configurations are likely to be vulnerable.

Postfix

Postfix does not typically export any attacker-controlled environment variables to subprocesses, so Postfix itself is not typically vulnerable.

$ /usr/sbin/postconf -d | grep export_environment
export_environment = TZ MAIL_CONFIG LANG
Figure 1: environment variables typically exported by Postfix

Many Postfix installations use procmail as an MDA, so see the section on procmail below.

qmail

If the recipient’s .qmail file contains any pipe commands, then qmail-local sets the attacker-controlled environment variables discussed in qmail-command and then invoke the shell. Therefore, many qmail configurations are likely to be vulnerable.

Procmail

Procmail does not automatically set any attacker-controlled environment variables. However, it is a very common procmail idiom to stuff mail headers into environment variables and then invoke the shell. The procmailex manpage gives several examples of this. Therefore many procmail configurations are likely to be vulnerable.

OpenVPN

OpenVPN can be configured to call out to a number of user-supplied helper programs. OpenVPN does not itself use the shell invoke them, but the programs themselves are usually shell scripts. Both the client and server set quite a lot of environment variables, a few of which, such as fields parsed out of the X.509 certificate, are plausibly attacker-controlled. Servers can cause clients (but not vice versa) to set $foreign_option_* to arbitrary values. Fredrik Strömberg points out that in some configurations the client can cause the server to process $username pre-auth. Many OpenVPN configurations are likely to be vulnerable.

stunnel

stunnel sets environment variables for the remote IP, and the subject and issuer distinguished name of the peer certificate. It doesn’t seem like it should be possible to cram the magic () { into the start of any of these fields, so stunnel appears unlikely to be vulnerable.

DHCP

Update. Thanks commenters ‘Nico’ and ‘Phil’, and ‘lambda’ from Hacker News.

dhclient invokes dhclient-script, which invokes all shell scripts in /etc/dhcp/dhclient-enter-hooks.d. It sets environment variables based on fields returned from the DHCP server. Essentially all dhclient configurations are vulnerable.

Others have reported that DHCP on Mac OS X is not vulnerable because it does not call out to any shell scripts. I haven’t verified this.