Two Chef vulnerabilities – one in Automate and one in InSpec -- have been discovered and documented as public CVEs. Fixes have been published and are available in the
community portal. These are critical vulnerabilities which the Chef Automate server and/or Chef InSpec processes. We take the security of Chef installations, both on customer premises and in our hosted environments, with the utmost priority and are announcing the availability of these fixes so you can take the steps necessary to harden your environments against vulnerability. At this time, we have no reports that these vulnerabilities have been exploited. Since the initial vulnerabilities were reported, we have worked diligently to protect our customers’ data and to provide fixes and guidance in a timely manner through our commitment to responsible disclosure.
While we have addressed the vulnerabilities with version-specific updates to these Chef products, the nature of this vulnerability requires special attention to your SDLC process and how you test and approve Chef content, including cookbooks and profiles.
We strongly encourage you to take the following actions immediately:
- Upgrade InSpec deployments to the latest version, the v4 or v5 releases.
- Upgrade Automate servers to the latest version.
- If you do not already have a program in place to approve InSpec profiles for use in production, review your active production profiles – both ones you have authored, as well as content from Chef and third-party sources – for specific malicious statements in the Ruby header sections.
It is critical that you immediately take action to apply the product changes and carefully assess your approach to harden your environment against these vulnerabilities.
First, a Little Context…
One of the primary uses of Chef Inspec is to run scans of application infrastructure to ensure that it is configured correctly. It can be executed by various mechanisms in Chef, including calls from the CLI (Command Line Interface) and from the Chef Automate UI. Based on how Chef is packaged, InSpec is included in different product combinations and is also included in newer releases of the Chef client.
Chef InSpec uses human readable policies in the form of cookbooks used by the configuration management product, Chef Infra. These policies implement CIS (Center for Internet Security) and DISA STIG standards and customers can extend this compliance framework with custom policies. Policies are effectively “content” supplied to a testing framework, either the InSpec command-line tool or an enterprise solution like Automate.
The policies are coded using a domain-specific language that is an extension of Ruby. Progress Chef provides curated content, which is out-of-the box policy files that encode CIS and other benchmarks. Customers and community members can also create or include custom policies, some of which are available through Automate or shared via repositories like Chef Supermarket, GitHub, websites, email, etc.
CVE Overview
A CVE – or “Common Vulnerability or Exposure” – is a way for customers to track risks in the software they may be using. The public notice of a CVE and the steps required to reduce the risk are documented in multiple online databases and are searchable within the national vulnerability database (https://nvd.nist.gov/) as well as other sites like MITRE’s (https://cve.mitre.org/index.html). As a part of routine security processes within Progress, we monitor external sources and apply internal tools to our products to find these critical vulnerabilities.
The two CVEs below were reported through our partnership with HackerOne, and were remediated with the latest versions of InSpec and Automate:
- CVE-2023-42658 - This is the primary CVE for Chef InSpec which identifies that the policy file code is executed as part of the InSpec archive, check and export commands. This is unexpected behavior based on the command names and allows a profile that includes certain malicious commands in the profile header (Ruby) to be executed locally. This CVE is present in the InSpec command line and also is represented in the CVE below, for cases where a profile is imported into Chef Automate, that the same commands are executed.
- CVE-2023-40050 - This CVE explains that the malicious code exploit present in earlier versions of InSpec can also be triggered by uploading content in Automate. A compliance profile with malicious code can be uploaded in the Automate user interface to execute arbitrary Ruby and/or shell commands on the system as the Automate system user, a privileged account. Since this exists on the server-side, malicious local code execution presents a threat to lateral resources and other servers in the Enterprise.
Both of these vulnerabilities require an unpatched version of InSpec or Automate and a malicious profile to be loaded by the DevOps engineer. We recommend all customers have a process for approving policies which may work well in a development environment but may not be suitable for production.
If an operator or engineer is using profiles which were created by a third-party, we strongly recommend testing the profile in a lower privilege environment such as development, and manually reviewing the actual Ruby code to make sure that each action in Compliance as Code is recognized and does what is intended. We have a new feature in InSpec 5 for signing profiles as part of a validation effort and have more to come on how we are building Zero Trust into our server products around content. The flexibility that Chef provides can lead to complex profiles where it may be relatively difficult to identify malicious code. Please review your profiles in use, especially where they do not come from within your organization.
This potential exploit can only be triggered when a Chef user performs an activity via the CLI or Automate UI, and only when the specific InSpec commands of archive, check, or export are called. The archive command is called within Automate when a profile (in .tar.gz format usually) is uploaded in the user interface. InSpec’s fix for this is detailed, and simply removes the execution of the Ruby profile on the commands in question. Automate’s remediation is forward-looking and we have implemented a sandbox so that bolt-on or integrated applications are restricted from network and file access: even if the application is compromised, no remote code execution due to the profile is possible.
Progress Chef Approach and Recommendation
For advanced organizations that are very aware of how Chef operates, the approach to execute the code as part of these commands is intentionally used in their workflows.
To address the possibility that the code is executed inadvertently or unknowingly, the Chef team will implement changes to Chef InSpec that will allow the users to indicate whether the code should be executed in the appropriate scenarios (including those listed above) to give our customers the option to execute or not execute the code.
We are also implementing changes to Chef Automate to enhance the permission model and provide better runtime isolation. This will help prevent malicious executions from the upload command that can negatively impact a single system or an enterprise environment. Infrastructure as Code and Compliance as Code will always have executable code – ideally a very flexible framework such as what Automate and InSpec provide – but we will continue to extend the permissions structure and visibility of operations being taken so that the operator has appropriate governance at runtime.
What Should You Do Now…
To update your InSpec and Automate deployments and address these two CVEs, please refer to the Knowledge Base articles for
Regardless of what Chef products or versions that you use, we strongly encourage you to read the Knowledge Base (KB) articles and best practice summary guide, devise the right strategy based on your Chef implementation and organizational processes, and then put those plans into action.
If you have any questions, concerns, or problems related to this issue, please raise a support request or reach out to your customer success manager.
For additional information or reporting vulnerabilities to any Progress products, refer to the Progress Security Center.