- What is the security vulnerability?
- Can I tell if I’m not vulnerable at all?
- What risk does this create? How would an attacker exploit this vulnerability?
- How serious is it? To what type of attack is my infrastructure exposed?
- How quickly do I need to address this vulnerability?
- What versions of Puppet open source and Puppet Enterprise are affected?
- Will upgrading Puppet fix the vulnerability?
- What do I need to do?
- What versions of Puppet will the remediation toolkit work with?
- Is the remediation toolkit proprietary?
- What does the remediation solution do?
- How long does remediation take?
- Has Puppet Labs tested this solution?
- How can I get additional help if I need it?
- I did not purchase a support contract with Puppet Labs, can I still get help?
- I did not purchase Puppet Enterprise, can I still get help?
- I signed-up to receive the Puppet Enterprise 2.0 release, does it have this vulnerability?
- I signed-up to receive the Puppet Enterprise 2.0 release, but didn’t receive an email on 10/21 with links to the software—when will it be available?
- I see Puppet Enterprise 1.2 is still available for download; does it have this vulnerability?
- When did Puppet Labs discover this vulnerability?
- How did Puppet Labs discover this vulnerability?
- Has Puppet Labs submitted this to the CVE list?
- Why didn’t Puppet Labs announce this earlier?
- Has any attacker exploited this vulnerability?
- What steps is Puppet Labs taking to mitigate security vulnerabilities like this in future releases?
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 here. 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.
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.
I signed up to receive the Puppet Enterprise 2.0 release, but didn’t receive the email with links to the software on 10/21—when will it be available?
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.