A bug in a configuration file setting causes the release of SSL certificates able to impersonate a Puppet master. Specifically, if the Puppet master setting "certdnsnames" is explicitly set in puppet.conf, then any agent certificate issued by the Puppet CA will contain the master's DNS names. Thus, anyone in possession of a certificate signed by the CA could impersonate the Puppet master and control any agent node that trusts one of the leaked DNS names. Under normal conditions, local root privileges are required to access such a certificate.
If you have never ever set the "certdnsnames" setting in your puppet.conf file, then you are not vulnerable, so long as you don’t turn it on before upgrading your Puppet master.
A malicious attacker with root access to a Puppet agent can impersonate a Puppet master, and could "snoop" Puppet traffic and mount a "man–in–the–middle" attack to attain root access on all Puppet–managed nodes within that environment.
A malicious attacker fully exploiting this vulnerability could take control of all systems which are managed by Puppet in the user’s environment.
Puppet Labs recommends customers and users take action as soon as possible to remediate this vulnerability. Download the remediation toolkit here.
- Puppet open source 0.24.x and later. (The puppet.conf configuration setting "certdnsnames" is not explicitly set in any version of Puppet open source.)
- For Puppet Enterprise, all versions (1.0, 1.1, 1.2) are affected. (The puppet.conf configuration setting "certdnsnames" is explicitly set in all versions of Puppet Enterprise.)
No. If any certificates with the master's DNS names have been released to agent nodes, they will remain dangerous until your agent nodes have been reconfigured.
Download the remediation toolkit. It contains documentation and tools to fully remediate the vulnerability.
It works with all versions of Puppet Enterprise, and a solution for a webrick Puppet master, versions 2.6.x or 2.7.x, has been provided.
No, it is licensed under the Apache 2.0 license, and source can be found here. We encourage users to fork it and adapt it for other deployment architectures.
At a high level, the remediation toolkit will help you:
- Remove the "certdnsnames" entry
- Create a new DNS entry for the Puppet master
- Issue a new Puppet master certificate with its new DNS name
- Migrate all Puppet agent nodes to contact the Puppet master at its new name
- Optionally, and at your convenience, replace the Puppet CA so you can resume use of your preferred DNS name.
In internal tests, the vulnerability was remediated from 20 Puppet–managed nodes and 1 Puppet Master server in just over an hour, with most of that time waiting for nodes to perform their regular Puppet run.
Yes. This remediation solution has been tested on all supported OS platforms for Puppet Enterprise masters and agents.
Our Customer Service Engineers are available to help via our #puppet IRC channel and our Puppet Users Google Groups.
Yes. Our Customer Service Engineers are available to help via our #puppet IRC channel and our Puppet Users Google Groups.
Yes. Our Customer Service Engineers are available to help via our #puppet IRC channel and our Puppet Users Google Groups.
No. We delayed work on Puppet Enterprise 2.0 to focus on remediating this vulnerability. In the process, we fixed this vulnerability in Puppet Enterprise 2.0.
As a result of our focus on addressing this vulnerability, Puppet Enterprise 2.0 availability has been delayed until Monday, November 14. If you signed up for Puppet Enterprise 2.0, you will receive an email on that day with links to the software.
Puppet Enterprise 1.2 has been remediated and, as of 05:00 PDT Monday, October 24, no longer has this vulnerability. Specifically, Puppet Enterprise releases from version 1.2.4 onward are protected.
Monday, October 10.
One of our engineers was working with and reviewing the SSL certificate handling code.
Yes. It is listed as CVE-2011-3872.
Puppet Labs subscribes to the principle of Responsible Disclosure (definition here), which allows time for the software developer to provide a remedy to the vulnerability prior to disclosure.
Not that we are aware.
Puppet Labs will retain a third party security consultancy to review our products for vulnerabilities for every major release.