September 24, 2014 Zach Lanier

Critical Vulnerability Discovered in Bash

What are we going with for this crazy critical bash vuln? Shellbleed? BASHed? Bourne Ultimatum?

— Mark Stanislav (@markstanislav) September 24, 2014

Here’s the tl;dr:

1. A critical (remote) code execution vulnerability affecting bash (Unix shell) was disclosed on September 24, 2014 (and manifested again, due to an incomplete patch, later that same day)
2. Duo customers using ForceCommand for SSH server configs (i.e. login_duo in the Duo Unix integration) may be vulnerable to a 2FA bypass
3. UPDATE TO THE LATEST VERSION OF BASH IMMEDIATELY!

The security of our service is of the utmost importance to us, and we've designed and built it that way. While our service is not directly affected by the bash vulnerabilities, our operations team has been staying up-to-date with pertinent patch information, and our Labs team has been conducting additional research around this issue.

UPDATE (September 26):

We've updated some parts of this post to reflect some recent developments, including other products that are affected.

• Unfortunately, the initial patch didn't consider all possible cases, leading to the assignment of another CVE (CVE-2014-7169). Additional patches were introduced, per a recent post on the OSS-Security mailing list. These patches were also considered somewhat incomplete, resulting in a third (slightly "Less Bad") vulnerability being cited

• Other targets are affected -- namely those built on Linux and Unix-like systems which pass user-controlled data to a vulnerable bash (see below)

• This is, unsurprisingly, being actively exploited in the wild:

• http://www.alienvault.com/open-threat-exchange/blog/attackers-exploiting-shell-shock-cve-2014-6721-in-the-wild

• http://www.wired.com/2014/09/hackers-already-using-shellshock-bug-create-botnets-ddos-attacks/

• http://blog.sucuri.net/2014/09/bash-shellshocker-attacks-increase-in-the-wild-day-1.html

• It wouldn't be a newsworthy vulnerability without logos and a dedicated site: https://shellshocker.net/ (actually a great resource, though you may want to think twice about piping curl output directly into your shell)

Now, the long(er) version...

Overview

On September 24, 2014, a critical remote code execution vulnerability affecting the "bash" Unix shell was publicly disclosed. This vulnerability stems from the way that bash handles specially-formatted environment variables, namely exported shell functions. Given that certain network clients pass these environment variables to servers, which then consume and honor these variables, an attacker could inject and subsequently execute arbitrary shell commands in applications or services that call bash.

To borrow an example from the excellent write-up by RedHat, below we see a bash environment variable, containing a function definition, being declared. Note the additional code appended to the end:

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

As a note, though some users may not be explicitly using bash as their personal shell or in scripts, some distributions may symlink /bin/sh to /bin/bash, which could give rise to this vulnerability unknowingly -- calls to popen() or system() in PHP, for example, could lead to exploitation (especially through the ability to influence/control HTTP-related environment variables used by PHP).

How does this affect Duo customers?

Customers using the ForceCommand directive (i.e. with login_duo) in their SSH server configurations may be vulnerable to this issue, which could lead to an attacker bypassing secondary authentication/2FA.

Outside of Duo’s Unix integration, other services may be affected. In particular, any service that has user (or attacker) controlled environment variables, subsequently passing them to affected versions of bash, may be vulnerable. Services configured to use SSH, such as git, subversion, rsync, etc., as well as other two-factor authentication platforms' SSH integrations, may be affected if the ForceCommand directive is being used.

Resolution/Fix

Customers using the Duo Unix integration (especially login_duo) should update to the latest, non-vulnerable version of bash. Many Linux distributions, including RedHat, CentOS, Ubuntu, and Arch have provided updated packages. For those wishing to build from source, the bash maintainer has published the source patch for bash 4.3.

UPDATE (09/26): The original patch was incomplete and didn't address the underlying issue. New patches have been shared via the OSS-Security mailing list. The Shellshocker website also provides instructions on applying the patch and building from source (but, again, think twice about curl output piped into your shell).

Per another post on OSS-Security, it seems even the second patch was somewhat incomplete -- though the resulting impact is far Less Bad than above, as an attacker would need influence over very specific environment variables.

Some vendor-specific advisories can be found as follows (also updated in the post on September 26):

Red Hat: https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2014-7169
Novell: http://support.novell.com/security/cve/CVE-2014-6271.html
Debian: https://www.debian.org/security/2014/dsa-3035
Ubuntu: http://www.ubuntu.com/usn/usn-2363-2//
Arch: https://bugs.archlinux.org/task/42109
F5: http://support.f5.com/kb/en-us/solutions/public/15000/600/sol15629.html
Juniper: https://kb.juniper.net/InfoCenter/index?page=content&id=JSA10648

Additionally, CERT has a running/updated list of affected vendors in Vulnerability Note VU#252743.

As for a workaround, unfortunately, aside from nixing bash altogether and breaking things you didn't know would break, there's not a great workaround for this. While some network services, such as OpenSSH, may allow for restricting which environment variables are honored, a proper fix to bash is really the best solution. (Note: even removing all the AcceptEnv directives in OpenSSH would still allow for SSH_ORIGINAL_COMMAND to be passed through, so that's pretty much moot).