We have announced command injection CVEs for two popular modules, puppetlabs-apt
, CVE-2022-3275, and puppetlabs-mysql
, CVE-2022-3276. Both modules have been updated to fix the CVEs, and the current releases on the Forge have been corrected. This type of flaw is common in the configuration management ecosystem, both for Puppet, and for other tools in the space.
What is the vulnerability? Am I vulnerable?
The threat model for this attack is untrusted users providing input to Puppet classes. If you are using the affected versions of the modules, puppetlabs-apt
earlier than 9.0.0 and puppetlabs-mysql
earlier than 13.0.0, a person who does not have access to modify your Puppet codebase can provide parameters via the console, Hiera data, the Foreman classification dashboard, or other integrations such as ServiceNow.
What should I do to mitigate it?
First, make sure you’re using a version of Puppet that supports the corrected modules. If you’re not, you need to upgrade. After you upgrade your software, you need to upgrade the modules to mitigate the CVE. If you’re not able to upgrade right away, there are steps included to help you mitigate the CVEs in a later section.
Do you need to upgrade Puppet Enterprise?
The following versions of Puppet Enterprise support the corrected modules, if you’re running an earlier version, you need to upgrade your primary server, any compiler nodes, and all agents.
-
Long-term support (LTS): 2019.8.8 or any later version of 2019.8, and PE 2021.7
-
Non-LTS (latest): PE 2021.3 or newer
Do you need to upgrade open source Puppet?
Our team doesn’t provide for support for open source Puppet, but we want to make sure you know about these CVEs and how to mitigate them. You can always get help from our community.
-
Puppet 6.x: 6.24 or later
-
Puppet 7.x: 7.9 or later
Why do I need to upgrade?
The command injection relies on command strings that are constructed from untrusted input, for example:
"/usr/bin/mycommand ${input_variable}"
Puppet versions 6.24 (PE 2019.8.8) and 7.9 (PE 2021.3) introduced a new, safer way, parameterized commands. Rather than a shell parsing a string command, it’s passed directly to the operating system with an array, for example:
["/usr/bin/mycommand", $input_variable]
The corrected modules use this type of command, so to use them, you need to use a version of the software that they’re compatible with. It will also help you keep modules up to date in the future, as we use paramaterized commands in more places.
After upgrading Puppet Enterprise (or Puppet), upgrade the modules
After you upgrade Puppet Enterprise (or Puppet), upgrade the modules using your standard content deployment process. The corrected versions of modules in the CVEs are puppetlabs-apt
version 9.0.0 and puppetlabs-mysql
version 13.0.0. As other modules we publish are updated for this type of vulnerability, you will see mentions of security or hardening in their changelogs.
If the new modules are installed on older versions of Puppet, what happens, and what should I do?
The new modules use parameterized commands. If you try to use corrected versions of the modules with older versions of Puppet that cannot process the array command, you get an error message similar to:
Error: Parameter command failed on Exec[mycommand]: Command must be a String, got value of class Array (line: 132)
If that happens, mitigate the CVEs by following these steps:
- Downgrade the affected modules by installing and deploying older versions that do not contain the security updates that caused the CVEs (
puppetlabs-apt
version 8.5.0, andpuppetlabs-mysql
version 12.0.3). - Use your standard upgrade process to upgrade Puppet or Puppet Enterprise.
- Finally, re-upgrade the affected modules, deploy them, and test that they continue to work as expected.
If I cannot upgrade right now, how do I mitigate the CVEs?
We recommend always running a supported version of Puppet Enterprise. If you are unable to upgrade, pin the affected modules versions to the last release prior to the security updates that caused the CVEs. For example, by adding these module pins to your Puppetfile.
mod 'puppetlabs-apt', '8.5.0'
mod 'puppetlabs-mysql', '12.0.3'
How can I learn to update my code to eliminate this kind of vulnerability?
We will create new security related documentation and tutorials over time. For now, start with this tutorial on writing secure Puppet code. Please follow our dev.to blog to learn more about security in the future.
How can we improve this article?
0 comments
Please sign in to leave a comment.
Related articles