Get Puppet Enterprise First 10 nodes are free!
Try it now
Request a demo
Automate IT and infrastructure, manage complex workflows, and mitigate risk at scale.
Try the full-featured Puppet Enterprise for free on 10 nodes.
Puppet Comply Find and prevent compliance failures
Compliance Enforcement Modules Remediate to stay in compliance
Continuous Delivery for Puppet Enterprise Build, test, and deploy infrastructure as code faster and easier
Content & Modules Pre-built scripts to automate common tasks
CentOS EOL Here’s how to secure your CentOS infrastructure – even after EOL.
Find thousands of component modules built by the community and guidance on using them in your own infrastructure.
Visit Puppet Forge >>
Open Source PuppetPerfect for individuals and small infrastructure
BoltAutomate tasks in orchestration workflows
See all open source projects >>
Contribute to open source projects >>
SECURITY MAIN > CVE 2011-3872 > FAQ
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.
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:
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.
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.