Page MenuHomePhabricator

"Shellshock" Bash Vulnerability
Closed, ResolvedPublic


IMPORTANT: Patch your systems! The "Shellshock" vulnerability can be used to perform limited privilege escalation in some Phabricator configurations.

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:

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:

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).

Event Timeline

epriestley claimed this task.
epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Security.
epriestley added subscribers: epriestley, btrahan, chad, hach-que.

Ugh -- I figured out a way to exploit this in the post-auth phase. I'll see if I can find a way to mitigate it, but I think all we can do is advise users to update bash.

I can't figure out a way to detect/mitigate this (we can't detect it pre-auth, and can't react to it post-auth), but I'll add a setup test for it, at least.

We haven't seen further relevant developments here and it seems like we've done everything we reasonably can on our side.