There is a new vulnerability in the commonly used Unix shell BASH, which the media is now calling Shellshock. Customers that have Critical Systems Protection/Data Center Security: Server Advanced can use their investments to protect their server infrastructure from this vulnerability.
Situation Overview: What is “Shellshock?”
A new vulnerability has been found that potentially affects most versions of the Linux and Unix operating systems, in addition to Mac OS X (which is based around Unix). Known as the “Bash Bug” or “ShellShock,” this vulnerability could allow an attacker to gain control over a targeted computer if exploited successfully.
The vulnerability affects Bash, a common component known as a shell that appears in many versions of Linux and Unix. Bash acts as a command language interpreter. In other words, it allows the user to type commands into a simple text-based window, which the operating system will then run.
To date, these are the CVEs for Shellshock (Source: http://www.zdnet.com/the-shellshock-faq-heres-what-you-need-to-know-7000034219/)
CVE-2014-6271: This is the original "Shellshock" Bash bug. When most people refer to the Bash bug or "Shellshock", they are most likely talking about this CVE.
CVE-2014-7169: This is the CVE assigned to the incomplete patch for the original bug. The original patch was found to be incomplete shortly after the vulnerability was publicly disclosed. A variation on the original malicious syntax may allow an attacker to perform unauthorized actions including writing to arbitrary files.
CVE-2014-7186 & CVE-2014-7187: These two CVEs are for bugs discovered in relation to the original Bash bug. These two bugs are triggered by syntax that is very similar to the original Bash bug, but instead of command injection, they allow for out of bounds memory access. There is currently no proof that these bugs have remote vectors and they have not been seen in the wild.
CVE-2014-6277 & CVE-2014-6278: Security researchers discovered two additional bugs. These two bugs are supposed to have the potential for arbitrary command injection, similar to the original Bash bug. However details have not been made public yet, in order to allow appropriate patches to be created.
For full details see the Security Response note:
For the latest updates, see the "Security Outbreak: Shellshock"
Are the Symantec Data Center Security & Compliance products vulnerable to Shellshock?
The Symantec Data Center& Compliance products, which include the following brands listed below are not vulnerable to this vulnerability:
- Symantec Data Center Security: Server and Server Advanced (DCS: S and DCS: SA)
- Critical Systems Protection (CSP)
- Control Compliance Suite (CCS)
- Enterprise Security Manager (ESM)
- Symantec Risk Automation Suite (SRAS)
How can customers leverage their investments in Critical Systems Protection (CSP)/ Data Center Security: Server Advanced (DCS: SA) to protect themselves against the Shellshock vulnerability?
CSP/DCS: SA can be used to protect server systems from the impact of this vulnerability by:
- Enabling the IPS functionality
- Enabling Full Application Control and Sandboxing
- Further Limiting the Root User
1. Enabling the IPS/IDS functionality:
Customers can take advantage of CSP/DCS:Server Advanced IPS capabilities in several ways:
- Deploy IPS Policies in Monitoring mode to, at least, alert the customers to activity that it would normally restrict or block. With this approach, the customer will not impede application performance, but it will have the ability to quickly detect and set alerts for unusual and suspicious activity.
- Ensure that the configuration files of both the *NIX OS and common Daemons/Applications, such as Apache, are READ-ONLY. These files can be accessed but not modified or deleted. This Read-Only setting goes beyond the usual *nix permission controls if required.
- Customers can also utilize the standard IDS Unix Baseline policy to monitor and run the following checks:
- Privileged Command
- Bash History Monitor
- System Hardening Monitor.
Customers can run checks across the top 5 categories to help detect potential unwanted activity. To minimize the potential impact of IDS checks on performance, the customers will have to do some tuning to remove all check options and reduce event traffic.
For exposed hosts, customers can apply the following policy settings:
- First version of the policy does not allow ANY modification to the Application configuration and content. These vital files are made "read-only" to any user or process including ROOT.
- Second version of the policy allows only specific user accounts to modify the files. The customer can enforce additional controls by limiting these changes to specific management applications, hosts or IP addresses. This policy can be tied into a customer’s Change Control Procedures, so that the first and more secure version of this policy is live 99% of the time. When changes are necessary or threats subside, the second version can then be applied, if desired.
Customer considerations:
- Customers will need to be aware of the trade-offs between operational costs and increased protection if they would like to invoke the ability to quickly switch between the first and second version of the policies.
- Customers also need to be aware that this security approach limits their ability to instantly update or modify an application.
- The approach outlined above is not limited to *Nix hosts, but can also be applied to Windows Application policies.
- IPS features within DCS:SA & CSP do require that an agent is installed and REBOOTED to enable functionality. In this instance, customers will have to consider the tradeoffs across downtime, operational cost, and risks to the organization.
- Symantec also recommends that all customers test IPS/IDS functionality, where possible, on test or preproduction systems before deploying on production hosts.
- Customers should also note that not all *NIX variants have the same IPS capabilities within DCS/CSP due to driver limitations within the OS. Customers should reference the Supported Platform feature Matrix for details .
2. Full Application Control and Sandboxing
As noted in the security bulletin, “the most likely route of attack is through Web servers utilizing CGI (Common Gateway Interface), the widely-used system for generating dynamic Web content.”
- CSP/DCS:Server Advanced can be used to protect systems from the impact of this vulnerability due to its ability to perform full application control. CSP/DCS:Server can ensure servers remain protected AND operational because it can limit processes which utilize bash to only perform their required functions.
- CSP/DCS:SA provides out-of-the-box protection for Apache, however, customers are advised to ensure that they have properly configured the sandbox for their environment.
Customer considerations:
- Customers have to properly configure the file resource lists so that only Apache has access to the web content.
- CSP/DCS:Server Advanced can also prevent CGI from running altogether.
- Customers should also note that in many instances, Apache web services are installed by default, but not used. In this scenario, CSP/DCS: Server Advanced can be used to block these unused Apache web services.
3. Limiting the Root User
CSP/DCS:SA can be used by customers to limit the root user's capabilities on Unix systems. Customers are advised to tune their Unix Prevention policy to ensure that the root user limits can be enforced even when a vulnerable version of bash is installed, thus preventing accidental exposures.
Using the Application Data Protection feature available in the 5.2.9 Unix Prevention policies, customers can tune the Unix Prevention policy and provide additional hardening of the CSP/DCS:SA self-protection within the policy. This hardening involves blocking root from starting or stopping the CSP/DCS:SA daemons, and blocking root from running the CSP/DCS:SA Collect Agent Info script. If the customer does need to perform these tasks, the workaround is to run the Agent Diagnostic policy from the CSP/DCS:SA Console to perform the action.
Policy tuning steps:
Using a 5.2.9 Unix Prevention policy from a 6.0 policy pack:
- Enable the option to “Show options normally hidden in the policy” on the main policy page.
- Edit the “Symantec Data Center Security Server Agent daemon [sdcssagent_ps]” sandbox. Under SCSCC Agent Application Data Protection:
a. Enable the option under SDCSS Agent Application File Data, “Block all access to the following SDCSS Agent files”.
b. Add the following paths under this option:
i. /etc/init.d/sisipsagent
ii. /etc/init.d/sisipsutil
iii. /etc/init.d/sisidsagent
iv. /etc/init.d/sisips.nfsd
v. /etc/init.d/sisids.init
vi. /etc/init.d/sisips.init
vii. %agentinstallroot%/tools/getagentinfo.sh
3. Edit the “Root Program Options [rootpriv_ps]” sandbox. Under Protection Categories, Application Data Protection:
a. Enable the option “Obey All Other Application Data Restrictions”