Change Details

A major vulnerability in bash was publicly disclosed yesterday. This task tracks our response to it. This 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: - `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. - `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).

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. This task tracks our response to it. This 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: - `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. - `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).

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. This task tracks our response to it. This 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: - `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. - `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).