A major vulnerability in bash was publicly disclosed yesterday (September 24). This task tracks our response to it.

This page has a pretty good overview of the vulnerability itself:

http://www.troyhunt.com/2014/09/everything-you-need-to-know-about.html

There is also a second, similar attack, which is still possible after the fix for the first one is applied. This one doesn't look quite as dangerous, at least so far:

https://access.redhat.com/security/cve/CVE-2014-7169

The short version is: an attacker who can control an environmental variable when bash executes can run arbitrary commands.

It appears that we're mostly in the clear on this (Update: we're not):

• sshd doesn't appear to pass ENV during the pre-auth SSH phase.
• We force no-pty, which appears to cover us during the post-auth SSH phase (nothing in ENV is, as far as I can tell, user-controllable).
  • In general, the way we sandbox SSH access should help limit vulnerability, but we pass the environment over sudo and the ssh user probably has significant access on many installs.
  • Update: There is a way for attackers to control an environment variable during this phase.
• mod_php and fcgi don't invoke a shell, so they do not appear to be directly vulnerable.
• Commands we execute from within Phabricator are vulnerable. However, the only environmental variable that appears controllable is PATH, and that's only controllable by administrators who have access to the machine already, and thus could run arbitrary commands in the first place, so this doesn't let an attacker escalate.

We also don't have much ability to respond in most of these cases:

• SSH pre-auth runs before we run code.
• We could reject requests in SSH pre-auth before they make it to SSH post-auth, but it looks like we get an empty ENV in pre-auth, so we can't actually do this. By the time we get to post-auth, any exploit would already have run.
• We can't reject requests fast enough if mod_php or fcgi are vulnerable: stuff would already have run by the time we could do anything.
• We do control sub-commands completely and could filter the environment. However, since there appears to be no way for attackers to control anything in the environment, and filtering is complex, and the second phase of the vulnerability may not be the end of it, I don't currently plan to pursue this.

From an ops perspective, I've patched our vulnerable machines with the first patch, but a patch isn't available for the second variant yet (although it does not appear to be as dangerous).