What is it?
Chances are, you’ve already heard about the recent discovery of what’s being called the “Shellshock” exploit in GNU Bash. This is a vulnerability that existed in Bash through versions that have span 25 years. However as it is a little used function, the exploit did not come into light till this week. The vulnerability can result in remote execution of arbitrary code.
Bash is widely used by many popular Linux distributions and Mac OS X. This means that the exposure surface is extremely large. As the bug has been in the wild for many years, it is unknown if this exploit have been used in the past.
Critical instances where the vulnerability may be exposed include:
- Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn subshells.
- Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allows arbitrary command execution capabilities.
- Allow arbitrary commands to run on a DHCP client machine, various Daemons and SUID/privileged programs.
- Exploit servers and other Unix and Linux devices via Web requests, secure shell, telnet sessions, or other programs that use Bash to execute scripts.
Am I affected?
For servers running RHEL/CentOS 5/6/7, our team was aware of the issue the same day it was made public on 24th September. Our team worked through the night to ensure the patch was applied within hours after it was released. The first patch was incomplete and we applied a 2nd patch the next day, once again within hours after the patch is available.
With respect to the above potential issues, we will like to explain how our managed servers using our default security policies are unaffected. We have kept it general on purpose:
- Most of our servers do not have mod_cgi in use. On top of that, we do not run PHP under CGI wrapper. Further to that, we restrict some key functions of PHP that would have made this a more dangerous bug such as system / exec.
- Most of our servers do not allow external shell access. For those that do, we do not use Bash as the shell. There are also other policies limiting access to only authorized users.
- We disable all unnecessary services including DHCP, etc during setup.
- Please refer to response 2 above. Another exposure surface we can foresee is the use of cron which may allow some users to put malicious commands. However, we currently do not run these jobs under Bash as well, but is using a separate shell.
If you have a specific area or question you like to clarify, please feel free to open a ticket with us. We will be happy to address any concerns directly for our clients.